This is the mail archive of the
binutils@sources.redhat.com
mailing list for the binutils project.
behavior of "strip -N" [[ added an example ]]
- From: Adam Megacz <adam at megacz dot com>
- To: binutils at sources dot redhat dot com
- Date: 29 Jan 2002 12:08:43 -0800
- Subject: behavior of "strip -N" [[ added an example ]]
- Organization: Myself
- References: <86sn8pt4xk.fsf@megacz.com>
Adam Megacz <adam@megacz.com> writes:
> I've noticed that when I strip a global symbol using strip -N and then
> link with --noinhibit-exec, the locations where that symbol's address
> would have been written get a 0x0 instead.
Here's a concrete example of what I'm talking about:
megacz@curry$ /usr/local/gcc/bin/i686-pc-mingw32-strip -g libgcj.a
megacz@curry$ /usr/local/gcc/bin/i686-pc-mingw32-objdump -r libgcj.a | grep -A4 \\[.text\$_GLOBAL__I__ZN4java2io19SyncFailedExceptionC1Ev
RELOCATION RECORDS FOR [.text$_GLOBAL__I__ZN4java2io19SyncFailedExceptionC1Ev]:
OFFSET TYPE VALUE
00000009 dir32 .data$_ZN4java2io19SyncFailedException6class$E
0000000e DISP32 __Jv_RegisterClass
megacz@curry$ /usr/local/gcc/bin/i686-pc-mingw32-strip -gN .data\$_ZN4java2io19SyncFailedException6class\$E libgcj.a
megacz@curry$ /usr/local/gcc/bin/i686-pc-mingw32-objdump -r libgcj.a | grep -A4 \\[.text\$_GLOBAL__I__ZN4java2io19SyncFailedExceptionC1Ev
RELOCATION RECORDS FOR [.text$_GLOBAL__I__ZN4java2io19SyncFailedExceptionC1Ev]:
OFFSET TYPE VALUE
00000009 dir32 __ZN4java2io19SyncFailedExceptionC1Ev
0000000e DISP32 __Jv_RegisterClass
Note that the relocation record's symbol changed when I stripped out
the section containing the target of the symbol (see the line starting
with "00000009" in each instance of grep)!
Shouldn't the relocation record retain the same value, which would be
an undefined symbol?
Can anybody explain this behavior?
- a