I am on a ia64 Gentoo/Hardened machine, testing the PIE support of gdb 7.1 against a very simple program. What I noticed is that gdb will successfully show the backtrace (including symbols and code) when run against a coredump (gdb ./test ./test.core), but not when working on the live executable (gdb ./test). The problem will vanish when the executable is compiled with -nopie. test.c, test, and test.core are attached. Portage 2.2_rc67 (hardened/linux/ia64/10.0/server, gcc-4.4.4, glibc-2.11.2-r0, 2.6.32-hardened-r11 ia64) ================================================================= System uname: Linux-2.6.32-hardened-r11-ia64-31-with-gentoo-2.0.1 Timestamp of tree: Sun, 08 Aug 2010 07:45:01 +0000 app-shells/bash: 4.0_p37 dev-lang/python: 2.6.4-r1, 3.1.2-r4 dev-util/cmake: 2.6.4-r3 sys-apps/baselayout: 2.0.1 sys-apps/openrc: 0.6.1-r1 sys-apps/sandbox: 2.2 sys-devel/autoconf: 2.65 sys-devel/automake: 1.10.3, 1.11.1 sys-devel/binutils: 2.20.1-r1 sys-devel/gcc: 4.4.4-r1 sys-devel/gcc-config: 1.4.1 sys-devel/libtool: 2.2.6b virtual/os-headers: 2.6.30-r1 ACCEPT_KEYWORDS="ia64" ACCEPT_LICENSE="* -@EULA" CBUILD="ia64-unknown-linux-gnu" CFLAGS="-pipe -mtune=mckinley -O2 -ftree-vectorize" CHOST="ia64-unknown-linux-gnu" CONFIG_PROTECT="/etc" CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/env.d /etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release /etc/php/apache2-php5/ext-active/ /etc/php/cgi- php5/ext-active/ /etc/php/cli-php5/ext-active/ /etc/revdep-rebuild /etc/sandbox.d /etc/terminfo /etc/texmf/language.dat.d /etc/texmf/language.def.d /etc/texmf/updmap.d /etc/texmf/web2c /etc/udev/rules.d" CXXFLAGS="-pipe -mtune=mckinley -O2 -ftree-vectorize" DISTDIR="/var/cache/portage/distfiles" EMERGE_DEFAULT_OPTS="--with-bdeps y" FEATURES="assume-digests distlocks fixpackages news parallel-fetch preserve-libs protect-owned sandbox sfperms strict unmerge-logs unmerge-orphans userfetch userpriv usersandbox usersync" GENTOO_MIRRORS="http://ftp.spline.inf.fu-berlin.de/mirrors/gentoo/ http://ftp- stud.fht-esslingen.de/pub/Mirrors/gentoo/ http://distfiles.gentoo.org" LANG="en_GB.UTF-8" LDFLAGS="-Wl,-O1 -Wl,--hash-style=gnu -Wl,--as-needed" MAKEOPTS="-j3" PKGDIR="/var/cache/portage/packages" PORTAGE_COMPRESS="xz" PORTAGE_CONFIGROOT="/" [...] PORTAGE_TMPDIR="/var/tmp" PORTDIR="/var/cache/portage/gentoo" PORTDIR_OVERLAY="/var/cache/portage/layman/sunrise /var/cache/portage/local" [...] Unset: CPPFLAGS, CTARGET, FFLAGS, INSTALL_MASK, LC_ALL, LINGUAS, PORTAGE_COMPRESS_FLAGS
Created attachment 4926 [details] sourcecode
Created attachment 4927 [details] executable
Created attachment 4928 [details] coredump
I do not have a Gentoo ia64 box available. But at least on RHEL-5.4.z.ia64: kernel-2.6.18-164.21.1.el5.ia64 gcc-4.1.2-46.el5_4.2.ia64 binutils-2.17.50.0.6-12.el5.ia64 glibc-2.5-42.el5_4.5.ia64 I do not see any problem with tested gdb-7.1.tar.bz2: GNU gdb (GDB) 7.1 Copyright (C) 2010 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "ia64-unknown-linux-gnu". For bug reporting instructions, please see: <http://www.gnu.org/software/gdb/bugs/>... Reading symbols from /root/jkratoch/redhat/piebug...done. (gdb) r Starting program: /root/jkratoch/redhat/piebug Program received signal SIGSEGV, Segmentation fault. 0x20000008000009b0 in hallo () at piebug.c:2 2 *(char*)0 = 0; (gdb) bt #0 0x20000008000009b0 in hallo () at piebug.c:2 #1 0x20000008000009f0 in main () at piebug.c:6 (gdb) q
I also see it only on my hardened box. Maybe you have a tip for how I could get closer to the cause of this? What is different between showing the backtrace of a coredump and a running program? And why does this difference only show when the application is compiled using PIE? The backtrace I get is: Program received signal SIGSEGV, Segmentation fault. 0x400007263aed0a90 in ?? () (gdb) bt full #0 0x400007263aed0a90 in ?? () No symbol table info available. #1 0x400007263aed0ad0 in ?? () No symbol table info available. Backtrace stopped: previous frame identical to this frame (corrupt stack?) (without -nopie) vs: Program received signal SIGSEGV, Segmentation fault. 0x4000000000000650 in hallo () at test.c:2 2 *(char*)0 = 0; (gdb) bt full #0 0x4000000000000650 in hallo () at test.c:2 No locals. #1 0x4000000000000690 in main () at test.c:6 No locals. (with -nopie)
(In reply to comment #5) > I also see it only on my hardened box. BTW I forgot to state that I really tested it for PIE: gcc -o piebug piebug.c -Wall -pie -fPIE -g > Maybe you have a tip for how I could get > closer to the cause of this? It crashed at 0x400007263aed0a90. At this moment see /proc/PID/maps, find which file (library?) covers this address, subtract its based address. Then run new GDB, load this file (library?), be sure to have its debug info (package *-debuginfo.rpm, AFAIK *-dbg on Debian, unaware of Gentoo), and type some disass or `info sym that-subtracted-address' (assuming prelink is not active at that moment, otherwise add also the prelinked base address). > What is different between showing the backtrace of a coredump and a running > program? I am curious, GDB does not affect much the inferior run, it more starts its work at the moment it crashes. Maybe you can also try to put some sleep() into the testcase and test how does it for for an "attach"ed inferior program. In fact you can also type (gdb) gcore at the crash moment for remote analysis. OTOH I am reluctant for more debugging as it seems to be more a Gentoo specific problem and you should rather file it for Gentoo.
A great part of the problem with gdb on hardened Gentoo stems from /proc/<pid>/auxv being empty, because you probably have said yes to "Remove addresses from /proc/<pid>/[smaps|maps|stat]" within kernel configuration. Please see http://bugs.gentoo.org/show_bug.cgi?id=341889 for details.
$ gcc -o test -g -pie test.c $ gdb ./test [...] Program received signal SIGSEGV, Segmentation fault. 0x4000061784dbca90 in hallo () at test.c:2 2 *(char*)0 = 0; Problem seems fixed in sys-devel/gdb-7.2 on Gentoo/Hardned/IA64.