GDB fails to set break points and cannot debug PIE executables. This is a bug for upstream; I'll find the gdb bugzilla and file a bug later. If anyone comes up with or finds a patch between now and whenever upstream fixes this, add a comment here.
John can you debug properly now? It was kinda known befoe you would not set break points within shared objects. More so if they are striped or built with fomit-frame-pointer. Please try the current gdb and report back.
Trying with gdb 6.3, emerge wants me to downgrade to 6.2.1-r1 now though. bluefox@icebox ~/data/programming/regression/src $ gcc -ggdb ssp_smash.c -o ssp_smash bluefox@icebox ~/data/programming/regression/src $ file ssp_smash ssp_smash: ELF 64-bit LSB shared object, AMD x86-64, version 1 (SYSV), not stripped bluefox@icebox ~/data/programming/regression/src $ gdb ./ssp_smash GNU gdb 6.3 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 "x86_64-pc-linux-gnu"...Using host libthread_db library "/lib/tls/libthread_db.so.1". (gdb) break main Breakpoint 1 at 0x9a0: file ssp_smash.c, line 22. (gdb) run Starting program: /home/bluefox/data/programming/regression/src/ssp_smash Warning: Cannot insert breakpoint 1. Error accessing memory address 0x9a0: Input/output error. Cannot insert breakpoint -2. Error accessing memory address 0x368f3e0610: Input/output error. (gdb)
paxctl -permsx and all that good stuff
see comment #3
Just for those coming across this looking for more detailed explanation :) Setting breakpoints requires write access to the the process being debugged. This obviously conflicts with PaX' p,s and m protections. Furthermore the calculations for breakpoint addresses can't cope with randomised base addresses, so the x and probably r protections also need to be disabled. It's simplest just to disable all PaX protections for the executable being debugged. For breakpoints in dynamic libraries to work, a separate issue nothing to do with PaX, there's a symbol/some symbols gdb needs from glibc which by default get stripped - sledgehammer solution is to emerge glibc with FEATURES="nostrip" to get this working. For completeness, as mentioned above don't set '-fomit-frame-pointer'; gdb has a much easier time of it unpicking the stack if the frames are setup properly.
John has a valid issue, I think. On various bits and bobs I've tried before, gdb has been ok. However I remembered I always generate non-pie executables for debugging (something I rigged up before but forgot about!). Linking a pie executable as John describes does indeed cause gdb to be unable to set breakpoints. Disabling RANDEXEC doesn't allow gdb to get around this. John, the GDB bug database (gnats) is at http://sources.redhat.com/gdb/ if you haven't found it already. Bug #1848 on the GDB bug database (submitted by a gentoo user 20th Jan 2005, who apparently did not speak to gentoo first, grr) has a response which says, "it seems gdb does support PIE, just not dynamically linked PIE". I don't really understand this; according to our SPECs, -static and -pie are incompatible which implies there's no such thing as a statically linked PIE for us. I suggest changing the resolution to RESOLVED/UPSTREAM.
