lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <c2d5cfd5-8bdb-4060-a974-18f9c2b9a2d0@yoseli.org>
Date: Mon, 2 Dec 2024 13:53:04 +0100
From: Jean-Michel Hautbois <jeanmichel.hautbois@...eli.org>
To: Tomas Glozar <tglozar@...hat.com>
Cc: Steven Rostedt <rostedt@...dmis.org>, linux-m68k@...ts.linux-m68k.org,
 linux-kernel@...r.kernel.org, linux-trace-kernel@...r.kernel.org,
 Geert Uytterhoeven <geert@...ux-m68k.org>, Greg Ungerer <gerg@...ux-m68k.org>
Subject: Re: [PATCH RFC 0/2] Add basic tracing support for m68k

Hi Tomas !

On 28/11/2024 16:25, Tomas Glozar wrote:
> po 18. 11. 2024 v 11:13 odesílatel Jean-Michel Hautbois
> <jeanmichel.hautbois@...eli.org> napsal:
>>
>> I had to modify the source code a bit, as it does not compile with my
>> uclibc toolchain:
>> ...
> 
> glibc added a gettid() wrapper with version 2.30; earlier glibc and
> uclibc do not have it. That can be fixed by conditionally including
> the inline function if on glibc lower than 2.30 or another libc; for
> reference on how to detect that, see how kernel self tests do it [1].

Thanks, I will cook a patch !

> 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.

>>
>> 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

> 
> [1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/tools/testing/selftests/nolibc/nolibc-test.c#n1008
> [2] https://git.kernel.org/pub/scm/libs/libtrace/libtraceevent.git/commit/?id=45a9b0647c904b7bf1240da5a11fe3a1ffd1006d
> 
> Tomas
> 


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ