This is the mail archive of the
binutils@sources.redhat.com
mailing list for the binutils project.
Re: objcopy does not realloc all symbols with --change-addresses
- To: Trent Waddington <trentw at vmware dot com>
- Subject: Re: objcopy does not realloc all symbols with --change-addresses
- From: Nick Clifton <nickc at redhat dot com>
- Date: 23 Mar 2001 15:41:27 -0800
- Cc: binutils at sources dot redhat dot com
- References: <Pine.LNX.4.21.0103211451230.873-100000@trentw-lx.vmware.com>
Hi Trent,
> Below is an example of the problem. Using --change-addresses to
> relocate the symbols contained in a binary to a new location fails
> to relocate all the symbols and in particular the symbols that gdb
> uses to calculate the addresses of functions.
Actually the problem is not that objcopy does not relocate symbols, it
is that it does not relocate data. The addresses that gdb uses comes
from the debug data in the debug sections. Objcopy will relocate the
sections and the symbols, but it cannot relocate the data because it
has no way of knowing the exact meaning of the data.
There is another way to reproduce this problem, which does not involve
debug debug information:
void blah (void) {}
void (* lobster)(void) = blah;
int main (void) { lobster (); }
Compile with 'gcc blah.c -o blah'.
Convert with 'objcopy --change-address 0xc0000000 blah blah1'
Try to run blah1. It will fail.
Load it into gdb:
% gdb -nw blah1
(gdb) p blah
$1 = {<text variable, no debug info>} 0xc80483e0 <blah>
(gdb) p/x lobster
$2 = 0x80483e0
(gdb) p & lobster
$3 = (<data variable, no debug info> *) 0xc8049498
There is no simple fix for this. If you need to create a working
executable with working debug information at a non-default address you
will have to create your own linker script and use that in your final
link.
Cheers
Nick