Re: R_386_RELATIVE question

[Ian Lance Taylor <iant at google dot com>]

Gregory Shtrasberg <shtras@gmail.com> writes:

> It's shared library because it's where I've encountered such a case for the
> first time. I guess it could have been any executable as well. 
> My point is that everywhere else when I tell the linker to preserve its
> relocations (-Wl,-q) if there is an address stored as a data, there is a
> relocation on it, which points to the address, so I can tell that it's
> actually an address and not some random data.
> It becomes important when I'm altering the binary. For example, I want to
> switch positions of two functions or insert nops in random places. That's
> what I mean by "reassembling". Of course then I need to fix all the
> addresses.
> And here is address that doesn't have such a relocation on it, though from
> what I know there should have been one and I'm trying to figure out why is
> that.
> So, basically there are two questions:
> 1. Am I right about that there should have been a relocation?
> 2. Why it isn't there?

I see what you are getting at.  The -q option copies the existing
relocations into the executable.  The R_386_RELATIVE reloc here is a
brand new relocation created by the linker.  One could imagine that the
linker would emit a different relocation when using -q, but it doesn't.
One could also imagine that it would leave the dynamic reloc alone but
would emit a new regular reloc, but it doesn't do that either.  I have
no opinion as to whether this is a bug.  There is no documented
behaviour for -q with shared libraries or for -q with dynamic
relocations.

I'll note that you do have all the information you need.  You can look
at the section contents to see what the R_386_RELATIVE refers to.  You
should be able to calculate how that address moves thanks to your
manipulations, and you should be able to adjust the section contents
accordingly.  But I agree that it would be more convenient and possibly
more reliable to have the symbol name.

Ian