GDB confused by -shared object executable

[Alex Bennee <kernel-hacker at bennee dot com>]

Hi,

For reasons of necessity we wanted out executable to run at the top of
64 bit memory space. This is because we want to stay out of the 32bit
memory space. We achieved this by building with:

CFLAGS =  -fpic -shared 
LDFLAGS =  -Wl,-e,_start

All this works fine (with a little hackage to initialise like a
library). However it confuses the hell out of GDB should we ever want to
do any debugging:

$ gdb ourprog
This GDB was configured as "x86_64-linux-gnu"...
Using host libthread_db library "/lib/libthread_db.so.1".
(gdb) start
Breakpoint 1 at 0x32e753: file ourprog/main.cc, line 67.
Starting program: ourprog
Warning:
Cannot insert breakpoint 1.
Error accessing memory address 0x32e753: Input/output error.

This is to be expected of course as our executable live way up high:

$ cat /proc/123456/map
<snip>
2b8268e6a000-2b8268fb1000 r-xp 00000000 08:01 1733565                    /lib/libc-2.5.so
2b8268fb1000-2b82691b1000 ---p 00147000 08:01 1733565                    /lib/libc-2.5.so
2b82691b1000-2b82691b4000 r-xp 00147000 08:01 1733565                    /lib/libc-2.5.so
2b82691b4000-2b82691b6000 rwxp 0014a000 08:01 1733565                    /lib/libc-2.5.so
2b82691b6000-2b82691bd000 rwxp 2b82691b6000 00:00 0 
2b82691bd000-2b82691be000 ---p 2b82691bd000 00:00 0 
2b82691be000-2b82692fe000 rwxp 2b82691be000 00:00 0 
2b82692fe000-2b82692ff000 r-xp 00000000 00:12 29833155                   /tmp/dynaEcmyWf (deleted)
2b82692ff000-2b82695c3000 rwxp 2b82692ff000 00:00 0 
555555554000-555555a32000 r-xp 00000000 08:04 12649433                   ourprog
555555b32000-555555b79000 rwxp 004de000 08:04 12649433                   ourprog
555555b79000-555555c77000 rwxp 555555b79000 00:00 0                      [heap]
7fff42c04000-7fff42c1a000 rwxp 7fff42c04000 00:00 0                      [stack]
ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0                  [vdso]

Running the binary with "r" works fine although you can't set any breakpoints in the code.
I suspect this is because the symbols in our shared object are relative.
It looks like the add-symbol-file should be able to handle this but I'm
not seeing it work.

(gdb) add-symbol-file ourprog 0x555555554000
add symbol table from file "ourprog" at
        .text_addr = 0x555555554000
(y or n) y
Reading symbols from ourprog...done
(gdb) x/5i main
0x32e740 <main>:        push   %rbp
0x32e741 <main+1>:      mov    %rsp,%rbp

Which doesn't seem to work. So questions:

1. Am I using the correct instantiation to load symbols at a particular
address?
2. Should GDB check the ELF when it loads it to see if it is an
executable shared object?

-- 
Alex, homepage: http://www.bennee.com/~alex/
"By golly, I'm beginning to think Linux really *is* the best thing since
sliced bread." (By Vance Petree, Virginia Power)