Gregory Shtrasberg <shtras@xxxxxxxxx> 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
