On Mon, Mar 11, 2024 at 9:34 AM James Clark <james.clark@xxxxxxx> 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
