Re: [PATCH v1 12/13] tools headers: Sync compiler.h headers

Ian Rogers
2024-03-11T19:24:36Z

On Mon, Mar 11, 2024 at 9:34 AM James Clark <james.clark@arm.com> wrote:
>
>
>
> On 10/03/2024 02:05, Ian Rogers wrote:
> > compiler.h - synced from include/linux/compiler.h, guards were
> > added to definitions to avoid redefinition of macros
> > in libc. ftrace, CONFIG_OBJTOOL and kentry logic was removed as
> > redundant.
> >
>
> Hi Ian,
>
> This commit breaks the Arm build (and cross compilation for Arm on x86):
>
> $ make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu-
>
> Something like this, but I won't paste the whole output because it's huge:
>
> tools/include/linux/ring_buffer.h: In function ‘ring_buffer_read_head’:
>
> tools/include/asm/../../arch/arm64/include/asm/barrier.h:72:35: error:
> ‘__u8_alias_t’ undeclared (first use in this function)
> 72 | : "=r" (*(__u8_alias_t *)__u.__c)
> \
> | ^~~~~~~~~~~~
> tools/include/linux/ring_buffer.h:59:16: note: in expansion of macro
> ‘smp_load_acquire’
> 59 | return smp_load_acquire(&base->data_head);
> | ^~~~~~~~~~~~~~~~

Sorry for this James, I was rushing. I'll address the issues in v2 but
the one you highlight above doesn't look like a fun/simple issue to
resolve :-( Tbh, I'm not sure how much value tools/include has in its
current set up. It is weird the include order in perf prefers
tools/include/linux over tools/include/uapi. Current tools/include
seems to be trying to do a few different things:

1) provide headers like list.h so programs in tools can have linux
style lists, etc.
2) stuff that (1) drags in .. do we really want the asm barrier code
from arm? A sane user space program would be better using stdatomic.h,
plus that'd give the user space program an ability to get compiled on
to weirder targets like wasm. Plus we end up with weird type conflicts
like bool coming from linux/types.h rather than stdbool.h.
3) copies of kernel uapi headers that may be more up-to-date that
those in your system, thereby exposing constants that things like
libbpf depend upon.
4) headers with the same name as and that resemble kernel headers but
are really a reimplementation, like tools/include/linux/string.h
5) headers we have just so we can use shell scripts to scrape
constants for beautifying things in perf trace

For (1) and (2) it seems a separate library would be cleaner than
having the code in tools/include.
(3) feels like a legit use-case, so we should hold onto
tools/include/uapi, but do we want the asm directories?
(4) sounds like it should be in a library, perhaps with (1) and (2).
(5) feels like the headers should be alongside the shell scripts to
avoid polluting tools/include.
Not that I propose fixing any of this here.

Thanks,
Ian

> Thanks
> James