Description of problem: Bug 216506 requests proper backtrace stopping on the toplevel clone() glibc function. Appropriate gdb patch (Bug 216506 Comment 6) would be provided but the associated CFI info in glibc would be needed. Otherwise some specific clone() hack can be implemented for gdb Version-Release number of selected component (if applicable): glibc-2.3.4-2.25.x86_64 How reproducible: Always. Steps to Reproduce: 1. gcc -o threader -ggdb3 -Wall threader.c -pthread 2. gdb ./threader 3. run 4. bt Actual results: #5 0x0000003f672c68c3 in clone () from /lib64/tls/libc.so.6 #6 0x0000000000000000 in ?? () (gdb) _ Expected results: #5 0x0000003f672c68c3 in clone () from /lib64/tls/libc.so.6 (gdb) _ Additional info: jakub: Is it fine to backport for glibc the RawHide glibc-2.5-11.x86_64/upstream patch? Patch for RHEL-4 resticted only for x86_64 as gdb stops for other reason on i386 (checked it is a different reason but did not analyse why specifically): 2006-11-30 Jan Kratochvil <jan.kratochvil> * sysdeps/unix/sysv/linux/x86_64/clone.S: Provide CFI for the outermost `clone' function to ensure proper unwinding stop of gdb. With the gdb patch of Attachment 143206 [details] this glibc patch will provide the final proper unwind as in the current RawHide with glibc-2.5.90-11.x86_64.
Created attachment 143207 [details] Testcase source
Created attachment 143208 [details] Patch providing unwindable CFI info for clone() - from upstream/RawHide
As libunwind already needed a patch for its assertion fail in RawHide glibc http://sources.redhat.com/cgi-bin/cvsweb.cgi/frysk-imports/libunwind/src/dwarf/Gparser.c.diff?r1=1.3&r2=1.4&cvsroot=frysk I believe it is not appropriate for RHEL-4 as it changes (CFI) glibc ABI. Fine to get it denied, just to get it confirmed you also believe it is the right way. Going to patch some hack in gdb(1) for the specific `clone' function instead.
Yeah, I think this isn't appropriate for RHEL4.