Re: R_386_RELATIVE question

[Gregory Shtrasberg <shtras@gmail.com>]

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?

And thanks again for your help.


Ian Lance Taylor-3 wrote:
> 
> Gregory Shtrasberg <shtras@gmail.com> writes:
> 
> You are looking at a shared library, created using gcc -shared.  I can
> tell because only shared libraries have R_386_RELATIVE relocations.  I'm
> not sure what you mean by "reassemble", but it is certainly true that
> you can not add new code to an existing shared library, any more than
> you can add new code to an existing fully linked executable.  A shared
> library essentially is an executable, just one that happens to be
> position independent.
> 
> Let me know if that does not make sense.
> 
> Ian
> 
> 

-- 
View this message in context: http://old.nabble.com/R_386_RELATIVE-question-tp30775689p30782769.html
Sent from the gcc - Help mailing list archive at Nabble.com.