From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22970 invoked by alias); 28 Sep 2007 16:01:35 -0000 Received: (qmail 22952 invoked by uid 22791); 28 Sep 2007 16:01:34 -0000 X-Spam-Check-By: sourceware.org Received: from mx.transitive.com (HELO pennyblack.transitives.com) (217.207.128.220) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 28 Sep 2007 16:01:27 +0000 Received: from [192.168.2.164] (helo=[192.168.2.164]) by pennyblack.transitives.com with esmtp (Exim 4.50) id 1IbIEF-0000yL-C4; Fri, 28 Sep 2007 15:58:12 +0000 Subject: GDB confused by -shared object executable From: Alex Bennee To: gdb@sourceware.org Cc: binutils@sourceware.org Content-Type: text/plain Date: Fri, 28 Sep 2007 16:05:00 -0000 Message-Id: <1190995357.27975.157.camel@murta.transitives.com> Mime-Version: 1.0 X-Mailer: Evolution 2.10.1 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2007-09/txt/msg00242.txt.bz2 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 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
: push %rbp 0x32e741 : 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)