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@xxxxxxxxx> 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.
