Hi Jean-Michel, po 2. 12. 2024 v 13:53 odesÃlatel Jean-Michel Hautbois <[email protected]> napsal: > > Thanks, I will cook a patch ! >
Thanks! > > As of the FOPTS changes: are those necessary for rtla to build, or > > were you just using them for easier debugging? AFAIK rtla shouldn't > > depend on unwind tables or stack protection for functionality. > > Well, my toolchain does not support it, so it fails at link time: > LINK /home/yocto/Projects/wabtec/linux/tools/tracing/rtla/rtla > /opt/m68k-buildroot-linux-uclibc_sdk-buildroot/bin/../lib/gcc/m68k-buildroot-linux-uclibc/13.3.0/../../../../m68k-buildroot-linux-uclibc/bin/ld: > /tmp/ccih6k6Z.ltrans0.ltrans.o: in function `err_msg': > /home/yocto/Projects/wabtec/linux/tools/tracing/rtla/src/utils.c:30:(.text+0x1a0): > undefined reference to `__stack_chk_guard' > /opt/m68k-buildroot-linux-uclibc_sdk-buildroot/bin/../lib/gcc/m68k-buildroot-linux-uclibc/13.3.0/../../../../m68k-buildroot-linux-uclibc/bin/ld: > /home/yocto/Projects/wabtec/linux/tools/tracing/rtla/src/utils.c:39:(.text+0x1e0): > undefined reference to `__stack_chk_guard' > <snip> > > That's why I removed this option. > Sorry, I misread the diff. I thought you were adding options, but you are just removing -fstack-protector-strong, right? I believe rtla should check for the feature first before adding -fstack-protector-strong, like perf does in tools/perf/Makefile.config: ifeq ($(feature-stackprotector-all), 1) CORE_CFLAGS += -fstack-protector-all endif The feature-stackprotector-all does a test build, if you have a toolchain where building with -fstack-protector-all is broken for any reason, it will return 0. You can try doing something similar for rtla. Tomas > >> > >> But it is not enough, as executing rtla fails with a segfault. > >> I can dump a core, but I could not manage to build gdb for my board so I > >> can't debug it (I don't know how to debug a coredump without gdb !). > >> > >> JM > >> > > > > I have seen a similar libtraceevent-related rtla segfault recently on > > ARM64, which was fixed by updating libtraceevent to a version that > > includes the fix. Such issues are caused by the files for kernel > > tracepoint tracefs having different contents on different > > architectures, exposing bugs. I see Steven has already fixed one of > > the issues on m68k [2]. > > I will try to use the very last versions of both libtracefs and > libtracevent and see if it is still happening ! > > Thanks ! > JM >
