R_386_RELATIVE question

R_386_RELATIVE question

[Gregory Shtrasberg]

Hello. I've got a question about the purpose of R_386_RELATIVE relocation
Here's a part of disassemble of a library, built as follows:
g++ -fPIC -c test.cpp -o test.o
g++ -shared -Wl,-q -o libtest.so test.o

At 0x1bcc there is a R_386_RELATIVE relocation, and the data in this address
is 0x1c08, which is an address of __dso_handle. As far as I understand, it's
not the job of R_386_RELATIVE to fix the value, so there should have been a
linker relocation on 0x1bcc, pointing to 0x1c08. Am I right? (There is no
other relocation on 0x1bcc besides R_386_RELATIVE)
Thanks in advance

Disassembly of section .got:

00001bcc <.got>:
    1bcc:       08 1c 00                or     %bl,(%eax,%eax,1)
                        1bcc: R_386_RELATIVE    *ABS*
        ...
                        1bd0: R_386_GLOB_DAT    __cxa_finalize
                        1bd4: R_386_GLOB_DAT    _Jv_RegisterClasses
                        1bd8: R_386_GLOB_DAT    __gmon_start__
Disassembly of section .got.plt:

00001bdc <.got.plt>:
    1bdc:       f4                      hlt
    1bdd:       1a 00                   sbb    (%eax),%al
        ...
    1be7:       00 42 06                add    %al,0x6(%edx)
                        1be8: R_386_JUMP_SLOT   _ZNSt8ios_base4InitC1Ev
    1bea:       00 00                   add    %al,(%eax)
    1bec:       52                      push   %edx
                        1bec: R_386_JUMP_SLOT   __cxa_atexit
    1bed:       06                      push   %es
    1bee:       00 00                   add    %al,(%eax)
    1bf0:       62 06                   bound  %eax,(%esi)
                        1bf0: R_386_JUMP_SLOT   _ZNKSsixEj
    1bf2:       00 00                   add    %al,(%eax)
    1bf4:       72 06                   jb     1bfc <.got.plt+0x20>
                        1bf4: R_386_JUMP_SLOT   _ZNKSs4sizeEv
    1bf6:       00 00                   add    %al,(%eax)
    1bf8:       82                      (bad)
                        1bf8: R_386_JUMP_SLOT   printf
    1bf9:       06                      push   %es
    1bfa:       00 00                   add    %al,(%eax)
    1bfc:       92                      xchg   %eax,%edx
                        1bfc: R_386_JUMP_SLOT   _ZSt3minIjERKT_S2_S2_
    1bfd:       06                      push   %es
    1bfe:       00 00                   add    %al,(%eax)
    1c00:       a2 06 00 00 b2          mov    %al,0xb2000006
                        1c00: R_386_JUMP_SLOT   __cxa_finalize
                        1c04: R_386_JUMP_SLOT   _ZNSt8ios_base4InitD1Ev
    1c05:       06                      push   %es
        ...
Disassembly of section .data:

00001c08 <__dso_handle>:
    1c08:       08 1c 00                or     %bl,(%eax,%eax,1)
                        1c08: R_386_RELATIVE    *ABS*
        ...


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

Re: R_386_RELATIVE question

[Ian Lance Taylor]

Gregory Shtrasberg <shtras@gmail.com> writes:

> Hello. I've got a question about the purpose of R_386_RELATIVE relocation
> Here's a part of disassemble of a library, built as follows:
> g++ -fPIC -c test.cpp -o test.o
> g++ -shared -Wl,-q -o libtest.so test.o
>
> At 0x1bcc there is a R_386_RELATIVE relocation, and the data in this address
> is 0x1c08, which is an address of __dso_handle. As far as I understand, it's
> not the job of R_386_RELATIVE to fix the value, so there should have been a
> linker relocation on 0x1bcc, pointing to 0x1c08. Am I right? (There is no
> other relocation on 0x1bcc besides R_386_RELATIVE)
> Thanks in advance
>
> Disassembly of section .got:
>
> 00001bcc <.got>:
>     1bcc:       08 1c 00                or     %bl,(%eax,%eax,1)
>                         1bcc: R_386_RELATIVE    *ABS*

The value 0x1c08 is already there, in the section contents (see the
bytes "08 1c" and recall that the i386 is little-endian).  The
R_386_RELATIVE directs the dynamic linker to adjust the value by the
load address of the shared library, so that at runtime it will be the
address where __dso_handle winds up.

Ian

Re: R_386_RELATIVE question

[Gregory Shtrasberg]

Thanks for the quick response.

What I ment to say is if I want to reassemble the code in some way, the
address of __dso_handle will change. Naturally, every other place that has
address in the data section has a linker relocation on it, like R_386_32,
which also tells me that the value is an address and needs to be altered. So
that I can change the value according to new code order, e.g. 08 1c 00 00
will become the new address of __dso_handle.
But here the only relocation here unlike other places is R_386_RELATIVE,
which, as you said does different thing.
So, this looks to me as some sort of bug in gcc. Or am I missing something?


Ian Lance Taylor-3 wrote:
> 
> Gregory Shtrasberg <shtras@gmail.com> writes:
> 
>> Hello. I've got a question about the purpose of R_386_RELATIVE relocation
>> Here's a part of disassemble of a library, built as follows:
>> g++ -fPIC -c test.cpp -o test.o
>> g++ -shared -Wl,-q -o libtest.so test.o
>>
>> At 0x1bcc there is a R_386_RELATIVE relocation, and the data in this
>> address
>> is 0x1c08, which is an address of __dso_handle. As far as I understand,
>> it's
>> not the job of R_386_RELATIVE to fix the value, so there should have been
>> a
>> linker relocation on 0x1bcc, pointing to 0x1c08. Am I right? (There is no
>> other relocation on 0x1bcc besides R_386_RELATIVE)
>> Thanks in advance
>>
>> Disassembly of section .got:
>>
>> 00001bcc <.got>:
>>     1bcc:       08 1c 00                or     %bl,(%eax,%eax,1)
>>                         1bcc: R_386_RELATIVE    *ABS*
> 
> The value 0x1c08 is already there, in the section contents (see the
> bytes "08 1c" and recall that the i386 is little-endian).  The
> R_386_RELATIVE directs the dynamic linker to adjust the value by the
> load address of the shared library, so that at runtime it will be the
> address where __dso_handle winds up.
> 
> Ian
> 
> 

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

Re: R_386_RELATIVE question

[Ian Lance Taylor]

Gregory Shtrasberg <shtras@gmail.com> writes:

> What I ment to say is if I want to reassemble the code in some way, the
> address of __dso_handle will change. Naturally, every other place that has
> address in the data section has a linker relocation on it, like R_386_32,
> which also tells me that the value is an address and needs to be altered. So
> that I can change the value according to new code order, e.g. 08 1c 00 00
> will become the new address of __dso_handle.
> But here the only relocation here unlike other places is R_386_RELATIVE,
> which, as you said does different thing.
> So, this looks to me as some sort of bug in gcc. Or am I missing something?

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

Re: R_386_RELATIVE question

[Gregory Shtrasberg]

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.

Re: R_386_RELATIVE question

[Ian Lance Taylor]

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