Re: [PATCH] perf arm64: Fix mksyscalltbl when system kernel headers are ahead of the kernel

[Vitaly Chikunov]

Arnaldo,

On Tue, May 21, 2019 at 03:03:54PM -0300, Arnaldo Carvalho de Melo wrote:
> Em Tue, May 21, 2019 at 12:19:18PM -0300, Arnaldo Carvalho de Melo escreveu:
> > Em Tue, May 21, 2019 at 04:34:47PM +0200, Michael Petlan escreveu:
> > > On Tue, 21 May 2019, Arnaldo Carvalho de Melo wrote:
> > > > Em Tue, May 21, 2019 at 06:02:03AM +0300, Vitaly Chikunov escreveu:
> > > > > When a host system has kernel headers that are newer than a compiling
> > > > > kernel, mksyscalltbl fails with errors such as:
> 
> > > > >   <stdin>: In function 'main':
> > > > >   <stdin>:271:44: error: '__NR_kexec_file_load' undeclared (first use in this function)
> > > > >   <stdin>:271:44: note: each undeclared identifier is reported only once for each function it appears in
> > > > >   <stdin>:272:46: error: '__NR_pidfd_send_signal' undeclared (first use in this function)
> > > > >   <stdin>:273:43: error: '__NR_io_uring_setup' undeclared (first use in this function)
> > > > >   <stdin>:274:43: error: '__NR_io_uring_enter' undeclared (first use in this function)
> > > > >   <stdin>:275:46: error: '__NR_io_uring_register' undeclared (first use in this function)
> > > > >   tools/perf/arch/arm64/entry/syscalls//mksyscalltbl: line 48: /tmp/create-table-xvUQdD: Permission denied
> 
> > > > > mksyscalltbl is compiled with default host includes, but run with
> 
> > > > It shouldn't :-\ So with this you're making it use the ones shipped in
> > > > tools/include? Good, I'll test it, thanks!
> 
> > > I've hit the issue too, this patch fixes it for me.
> > > Tested.
> 
> > Thanks, I'll add your Tested-by, appreciated.
> 
> Was this in a cross-build environment? Native?

It was native build on aarch64 with both 'hostcc' and 'gcc' arguments of
mksyscalltbl being set to gcc.

> I'm asking because I test
> this on several cross build environments, like on ubuntu 19.04 cross
> building to aarch64:
> ... 
> I.e. it didn't fail the build, but in the end these new syscalls are not
> there, while with your patch, they are:

Probably in your case system headers was older than kernel you are
building so you just silently losing syscalls.

> Thanks, applied.

Thanks!

> 
> - Arnaldo