behavior of "strip -N"

behavior of "strip -N"

[Adam Megacz]

Hi,

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.

However, when I strip a file-local symbol, those locations seem to get
written with the address of the start of the section they fall in.

Is there any way to get the first behavior (0x0) when stripping
file-local symbols?

Context: I'm writing a post-compile, pre-link processor for
applications compiled with gcj (the GNU java-to-native-code static
compiler). The processor does high-level reachability analysis and
prunes unreachable methods and classes. There are some cases where I
need a 0x0 to be written into the code where the address of a deleted
method/class would have formerly lived. No, I can't integrate this
into the compiler.

  - a

behavior of "strip -N" [[ added an example ]]

[Adam Megacz]

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

Re: behavior of "strip -N"

[Ian Lance Taylor]

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.
> 
> However, when I strip a file-local symbol, those locations seem to get
> written with the address of the start of the section they fall in.
> 
> Is there any way to get the first behavior (0x0) when stripping
> file-local symbols?

What happens when you do this is processor and object file format
dependent.  The fact that you get a zero in some cases is a
coincidence.  The fact that you get the address of the start of the
section in other cases is also a coincidence.

To make this reliable, you would need to track down many many cases in
the linker code which currently report an undefined symbol, and change
them to relocate using a value of zero rather than not bothering to do
any relocation at all.

Ian

Re: behavior of "strip -N"

[Adam Megacz]

Ian Lance Taylor <ian@airs.com> writes:
> > Is there any way to get the first behavior (0x0) when stripping
> > file-local symbols?

> What happens when you do this is processor and object file format
> dependent.

Bummer. Is there any way to redefine a file-local symbol via binutils?
I suppose I could redefine the symbol to ABSOLUTE(0x0).

  - a

Re: behavior of "strip -N"

[Ian Lance Taylor]

Adam Megacz <adam@megacz.com> writes:

> Ian Lance Taylor <ian@airs.com> writes:
> > > Is there any way to get the first behavior (0x0) when stripping
> > > file-local symbols?
> 
> > What happens when you do this is processor and object file format
> > dependent.
> 
> Bummer. Is there any way to redefine a file-local symbol via binutils?
> I suppose I could redefine the symbol to ABSOLUTE(0x0).

Do you mean in the linker?  The answer is no.

I think you have some sort of misconception about file-local symbols.
From the linker's point of view, a file-local symbol has no name.  The
only names the linker deals with are globally visible.  There is no
way in the linker to refer to a name which is specific to a particular
object file.

Ian