+++ This bug was initially created as a clone of Bug #231327 +++ Summary: Gdb does not accurately output the backtrace. Version-Release of Selected Component: gdb-6.6-5.fc7.ppc64 Description of Problem: A core was created by gcore command of gdb. I tried to debug with gdb, but I found that backtrace wasn't output correctly. Using host libthread_db library "/lib64/tls/libthread_db.so.1". Core was generated by `./small'. Program terminated with signal 11, Segmentation fault. Reading symbols from /lib/tls/libc.so.6...done. Loaded symbols for /lib/tls/libc.so.6 Reading symbols from /lib/ld.so.1...done. Loaded symbols for /lib/ld.so.1 #0 0x0fe91038 in kill () from /lib/tls/libc.so.6 Thread 1 (process 21873): #0 0x0fe91038 in kill () from /lib/tls/libc.so.6 #1 0x10000584 in handle_alrm (signo=14) at small.c:17 #2 <signal handler called> #3 0x0fef5fec in __pause_nocancel () from /lib/tls/libc.so.6 #4 0x10000650 in main (argc=1, argv=0xffffe9d4) at small.c:32 RESULT of kernel core generator: Passed Using host libthread_db library "/lib64/tls/libthread_db.so.1". Attaching to program: /mnt/tests/kernel/syscalls/vsyscall/small, process 21887 Reading symbols from /lib/tls/libc.so.6...done. Loaded symbols for /lib/tls/libc.so.6 Reading symbols from /lib/ld.so.1...done. Loaded symbols for /lib/ld.so.1 0x0fef5fec in __pause_nocancel () from /lib/tls/libc.so.6 Saved corefile core.gcore Using host libthread_db library "/lib64/tls/libthread_db.so.1". Core was generated by `/mnt/tests/kernel/syscalls/vsyscall/small'. Reading symbols from /lib/tls/libc.so.6...done. Loaded symbols for /lib/tls/libc.so.6 Reading symbols from /lib/ld.so.1...done. Loaded symbols for /lib/ld.so.1 #0 0x00000000 in ?? () Thread 1 (process 21887): #0 0x00000000 in ?? () #1 0x00000000 in ?? () RESULT of kernel maps permissions: Failed RESULT: some tests Failed -- Additional comment from anderson on 2007-03-09 15:00 EST -- The problem seen here is with gcore-generated core files. Using the supplied "small.c" program, and letting it kill itself via SIGSEGV, and then having the kernel generate a core file, gdb works OK: # gdb small core.831 GNU gdb Red Hat Linux (6.3.0.0-1.132.EL4rh) Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "ppc64-redhat-linux-gnu"...Using host libthread_db library "/lib64/tls/libthread_db.so.1". Core was generated by `./small'. Program terminated with signal 11, Segmentation fault. Reading symbols from /lib/tls/libc.so.6...done. Loaded symbols for /lib/tls/libc.so.6 Reading symbols from /lib/ld.so.1...done. Loaded symbols for /lib/ld.so.1 #0 0x0feb1038 in kill () from /lib/tls/libc.so.6 (gdb) bt #0 0x0feb1038 in kill () from /lib/tls/libc.so.6 #1 0x10000584 in handle_alrm (signo=14) at small.c:17 #2 <signal handler called> #3 0x0ff15fec in __pause_nocancel () from /lib/tls/libc.so.6 #4 0x10000650 in main (argc=1, argv=0xffffeae4) at small.c:32 (gdb) But if generated by gcore, it does not: # gdb small core.837 GNU gdb Red Hat Linux (6.3.0.0-1.132.EL4rh) Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "ppc64-redhat-linux-gnu"...Using host libthread_db library "/lib64/tls/libthread_db.so.1". Core was generated by `/mnt/tests/kernel/syscalls/vsyscall/small'. Reading symbols from /lib/tls/libc.so.6...done. Loaded symbols for /lib/tls/libc.so.6 Reading symbols from /lib/ld.so.1...done. Loaded symbols for /lib/ld.so.1 #0 0x00000000 in ?? () (gdb) bt #0 0x00000000 in ?? () #1 0x00000000 in ?? () (gdb) -- Additional comment from jan.kratochvil on 2007-03-09 16:52 EST -- Confirming I also see it as a GDB.ppc bug now. Thanks for such perfectly prepared machine, going to check it on that RHTS host until it expires. -- Additional comment from jan.kratochvil on 2007-03-09 17:33 EST -- The problem exists only for 64-bit GDB (gdb.ppc64) debugging (32-bit) process (ppc). Bug is in the gcore writing. Registers content gets corrupted. Memory areas look to be transferred OK. [snip] -- Additional comment from jan.kratochvil on 2007-03-13 11:47 EST -- [snip] Bug IS present in: RawHide gdb-6.6-5.fc7.ppc64 Bug is NOT present in: upstream gdb-6.6 Bug is NOT present in: upstream HEAD Apparently some Red Hat patches are causing a PPC regression.
Bug was present in all the versions. "NOT present in upstream" note above was a build mistake (ppc only build). Committed to Rawhide, testcased by the recently updated `gdb.base/gcore.exp': * Wed Apr 25 2007 Jan Kratochvil <jan.kratochvil> - 6.6-13 - Fix `gcore' command for 32bit PPC inferiors on 64bit PPC hosts (BZ 232015).
Upstream status: A different patch with the same goal was posted by IBM, so far not accepted: http://sources.redhat.com/ml/gdb-patches/2007-01/msg00455.html http://sources.redhat.com/ml/gdb-patches/2007-02/msg00076.html This patch depends on the i386-on-x86_64 patch posted by me, so far not accepted: http://sources.redhat.com/ml/gdb-patches/2006-09/msg00159.html Therefore this patch was so far not posted upstream.