Re: tools/bpf: Compilation issue on powerpc: unknown type name '__vector128'

Re: tools/bpf: Compilation issue on powerpc: unknown type name '__vector128'

[Vitaly Chikunov]

Adding netdev and PowerPC maintainers JFYI.

On Sat, Oct 24, 2020 at 11:23:19AM +0300, Dmitry V. Levin wrote:
> Hi,
> 
> On Sat, Oct 24, 2020 at 02:06:41AM +0300, Vitaly Chikunov wrote:
> > Hi,
> > 
> > Commit f143c11bb7b9 ("tools: bpf: Use local copy of headers including
> > uapi/linux/filter.h") introduces compilation issue on powerpc:
> >  
> >   builder@powerpc64le:~/linux$ make -C tools/bpf V=1
> >   make: Entering directory '/usr/src/linux/tools/bpf'
> >   gcc -Wall -O2 -D__EXPORTED_HEADERS__ -I/usr/src/linux/tools/include/uapi -I/usr/src/linux/tools/include -DDISASM_FOUR_ARGS_SIGNATURE -c -o bpf_dbg.o /usr/src/linux/tools/bpf/bpf_dbg.c
> >   In file included from /usr/include/asm/sigcontext.h:14,
> > 		   from /usr/include/bits/sigcontext.h:30,
> > 		   from /usr/include/signal.h:291,
> > 		   from /usr/src/linux/tools/bpf/bpf_dbg.c:51:
> >   /usr/include/asm/elf.h:160:9: error: unknown type name '__vector128'
> >     160 | typedef __vector128 elf_vrreg_t;
> > 	|         ^~~~~~~~~~~
> >   make: *** [Makefile:67: bpf_dbg.o] Error 1
> >   make: Leaving directory '/usr/src/linux/tools/bpf'
> 
> __vector128 is defined in arch/powerpc/include/uapi/asm/types.h;
> while include/uapi/linux/types.h does #include <asm/types.h>,
> tools/include/uapi/linux/types.h doesn't, resulting to this
> compilation error.

This is too puzzling to fix portably.

Thanks,

> 
> 
> -- 
> ldv

Re: tools/bpf: Compilation issue on powerpc: unknown type name '__vector128'

[Michael Ellerman]

Vitaly Chikunov <vt@altlinux.org> writes:
> Adding netdev and PowerPC maintainers JFYI.

Thanks.

> On Sat, Oct 24, 2020 at 11:23:19AM +0300, Dmitry V. Levin wrote:
>> Hi,
>> 
>> On Sat, Oct 24, 2020 at 02:06:41AM +0300, Vitaly Chikunov wrote:
>> > Hi,
>> > 
>> > Commit f143c11bb7b9 ("tools: bpf: Use local copy of headers including
>> > uapi/linux/filter.h") introduces compilation issue on powerpc:
>> >  
>> >   builder@powerpc64le:~/linux$ make -C tools/bpf V=1
>> >   make: Entering directory '/usr/src/linux/tools/bpf'
>> >   gcc -Wall -O2 -D__EXPORTED_HEADERS__ -I/usr/src/linux/tools/include/uapi -I/usr/src/linux/tools/include -DDISASM_FOUR_ARGS_SIGNATURE -c -o bpf_dbg.o /usr/src/linux/tools/bpf/bpf_dbg.c

Defining __EXPORTED_HEADERS__ is a hack to circumvent the checks in the
uapi headers.

So first comment is to stop doing that, although it doesn't actually fix
this issue.

>> >   In file included from /usr/include/asm/sigcontext.h:14,
>> > 		   from /usr/include/bits/sigcontext.h:30,
>> > 		   from /usr/include/signal.h:291,
>> > 		   from /usr/src/linux/tools/bpf/bpf_dbg.c:51:
>> >   /usr/include/asm/elf.h:160:9: error: unknown type name '__vector128'
>> >     160 | typedef __vector128 elf_vrreg_t;
>> > 	|         ^~~~~~~~~~~
>> >   make: *** [Makefile:67: bpf_dbg.o] Error 1
>> >   make: Leaving directory '/usr/src/linux/tools/bpf'
>> 
>> __vector128 is defined in arch/powerpc/include/uapi/asm/types.h;
>> while include/uapi/linux/types.h does #include <asm/types.h>,
>> tools/include/uapi/linux/types.h doesn't, resulting to this
>> compilation error.
>
> This is too puzzling to fix portably.

I don't really understand how this is expected to work.

We have tools/include/uapi/linux/types.h which is some sort of hand
hacked types.h, but doesn't match the real types.h from
include/uapi/linux.

In particular the tools/include types.h doesn't include asm/types.h,
which is why this breaks.

I can build bpf_dbg if I copy the properly exported header in:

  $ make INSTALL_HDR_PATH=$PWD/headers headers_install
  $ cp headers/include/linux/types.h tools/include/uapi/linux/
  $ make -C tools/bpf bpf_dbg
  make: Entering directory '/home/michael/linux/tools/bpf'
  
  Auto-detecting system features:
  ...                        libbfd: [ on  ]
  ...        disassembler-four-args: [ on  ]
  
    CC       bpf_dbg.o
    LINK     bpf_dbg
  make: Leaving directory '/home/michael/linux/tools/bpf


I'm not sure what the proper fix is.

Maybe sync the tools/include types.h with the real one?

Or TBH I would have thought the best option is to not have
tools/include/uapi at all, but instead just run headers_install before
building and use the properly exported headers.

cheers

Re: tools/bpf: Compilation issue on powerpc: unknown type name '__vector128'

[Will Deacon]

On Mon, Oct 26, 2020 at 03:45:55PM +1100, Michael Ellerman wrote:
> Vitaly Chikunov <vt@altlinux.org> writes:
> > Adding netdev and PowerPC maintainers JFYI.
> 
> Thanks.
> 
> > On Sat, Oct 24, 2020 at 11:23:19AM +0300, Dmitry V. Levin wrote:
> >> Hi,
> >> 
> >> On Sat, Oct 24, 2020 at 02:06:41AM +0300, Vitaly Chikunov wrote:
> >> > Hi,
> >> > 
> >> > Commit f143c11bb7b9 ("tools: bpf: Use local copy of headers including
> >> > uapi/linux/filter.h") introduces compilation issue on powerpc:
> >> >  
> >> >   builder@powerpc64le:~/linux$ make -C tools/bpf V=1
> >> >   make: Entering directory '/usr/src/linux/tools/bpf'
> >> >   gcc -Wall -O2 -D__EXPORTED_HEADERS__ -I/usr/src/linux/tools/include/uapi -I/usr/src/linux/tools/include -DDISASM_FOUR_ARGS_SIGNATURE -c -o bpf_dbg.o /usr/src/linux/tools/bpf/bpf_dbg.c
> 
> Defining __EXPORTED_HEADERS__ is a hack to circumvent the checks in the
> uapi headers.
> 
> So first comment is to stop doing that, although it doesn't actually fix
> this issue.
> 
> >> >   In file included from /usr/include/asm/sigcontext.h:14,
> >> > 		   from /usr/include/bits/sigcontext.h:30,
> >> > 		   from /usr/include/signal.h:291,
> >> > 		   from /usr/src/linux/tools/bpf/bpf_dbg.c:51:
> >> >   /usr/include/asm/elf.h:160:9: error: unknown type name '__vector128'
> >> >     160 | typedef __vector128 elf_vrreg_t;
> >> > 	|         ^~~~~~~~~~~
> >> >   make: *** [Makefile:67: bpf_dbg.o] Error 1
> >> >   make: Leaving directory '/usr/src/linux/tools/bpf'
> >> 
> >> __vector128 is defined in arch/powerpc/include/uapi/asm/types.h;
> >> while include/uapi/linux/types.h does #include <asm/types.h>,
> >> tools/include/uapi/linux/types.h doesn't, resulting to this
> >> compilation error.
> >
> > This is too puzzling to fix portably.
> 
> I don't really understand how this is expected to work.
> 
> We have tools/include/uapi/linux/types.h which is some sort of hand
> hacked types.h, but doesn't match the real types.h from
> include/uapi/linux.
> 
> In particular the tools/include types.h doesn't include asm/types.h,
> which is why this breaks.
> 
> I can build bpf_dbg if I copy the properly exported header in:
> 
>   $ make INSTALL_HDR_PATH=$PWD/headers headers_install
>   $ cp headers/include/linux/types.h tools/include/uapi/linux/
>   $ make -C tools/bpf bpf_dbg
>   make: Entering directory '/home/michael/linux/tools/bpf'
>   
>   Auto-detecting system features:
>   ...                        libbfd: [ on  ]
>   ...        disassembler-four-args: [ on  ]
>   
>     CC       bpf_dbg.o
>     LINK     bpf_dbg
>   make: Leaving directory '/home/michael/linux/tools/bpf
> 
> 
> I'm not sure what the proper fix is.
> 
> Maybe sync the tools/include types.h with the real one?

Yeah, all f143c11bb7b9 did was sync the local copy with the result of
'headers_install', so if that's sufficient then I think that's the right
way to fix the immediate breakage.

> Or TBH I would have thought the best option is to not have
> tools/include/uapi at all, but instead just run headers_install before
> building and use the properly exported headers.

Agreed, although in some cases I suspect that kernel-internal parts are
being used.

Wiil