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