Printable View
Why is there a need for relocation table when every element in an exe is at a relative offset from the base of the image?? I mean even if the image gets dispacled by a positive offset of say 0X60000, where is the need for relocation table, as we would anyways be using RVA's which would be relative to the new base??
I'm a bit rusty on some of this low level stuff but here goes. My friends here can correct me where I'm wrong.
You essentially answered your own question. It does not affect the code because addresses are relative to the base address of where the image is loaded. The need for relocation is to allow an image to be loaded in at any address and run correctly regardless of the base address. If you built code that had to be at a specific address it might not run on certain machines since it is highly likely that address will be in use. You can specify base addresses of DLLs and EXEs in MSVS and this is extremely useful for certain types of debugging as long as you know what you are doing and the general memory layout of your particular machine at a given time. This can be useful when doing remote debugging on embedded systems since it is likely the embedded system (read: Win XPE or Windows Embedded Standard) will not have nearly as many programs and services running as a normal everyday system. It is relatively safe, easy, and sometimes necessary to specify the base address on embedded systems.
The EXE doesn't need to be relocated by itself but the EXE supports relocation b/c the OS will definitely relocate it. So the file format supports relocation but really only requires that it be loaded at some base address. For more information about the Windows PE file format you can check MSDN. There is also a lot of information about other executable file formats on the internet.
Note that this info applies to native code. I am not sure of the exact loading and fixup process for managed assemblies.
Ya, but where is the need for relocation table, because all the refernces are anyways relative??
I think relocations are mostly for object files, not executables.
Only code references are PC-relative. The x86 architecture does not provide PC-relative data addressing. In other words if you have some static data like a global variable, it must be addressed with an absolute, not relative, address.Quote:
Originally Posted by juice
On Windows, executables have a fixed base address unless otherwise specified. Therefore an EXE does not need data relocation entries. DLLs, on the other hand, can be rebased at runtime and therefore must include relocations for all of their static data items.
Right. I forgot about DLLs.
Why can't the global data be at relative offsets?? Doesn't all the data go into the .data section which itself is at a relative offset from the base of the image..Quote:
Originally Posted by brewbuck
How does the EXECUTING CODE know where it is? As I said, there is no such thing as PC-relative data addressing on x86 architectures.Quote:
Originally Posted by juice
If you still don't get it, do the following: write me an assembly language instruction (a single instruction) which accesses the DWORD a distance of 1000 bytes away from the instruction. You'll find that it is not possible.
O_oQuote:
Why can't the global data be at relative offsets?
They can be. It just happens that some platforms directly support it, some don't, and others require some expensive trickery.
You have missed something important in what brewbuck is saying.Quote:
Doesn't all the data go into the .data section which itself is at a relative offset from the base of the image.
The program loader, the bit of the operating system that reads a "PE" format executable and loads it into memory, patches offsets, what he said as "rebased", for global data.
That is something that the operating system is doing. If the hardware fully supported "PIC" that trickery wouldn't be necessary. The compiler could, for example, stuff global data entries relative to an offset, store an additional offset per function using that global data at a known offset from a specific instruction within that function, and combine those offsets to get a true offset from the program counter.
o_OQuote:
a single instruction
Why does it have to be a single instruction?
I'm not joking; I don't get the requirement.
I could write some assembler to address data relative to the program counter even on x86. (Granted, I'd have to modify the linker to patch the relative offset for it to be practical.) The code would certainly take a lot more than one instruction. I think it takes more than one to get the program counter. (I'm not going to do this kludge; I have no interest in counting instructions over and over again to debug code for something I don't see as useful.) The "one instruction" thing seems like weird requirement. (I guess you probably can do it with one instruction on x86-64.) It isn't practical to do this by hand anyway.
Soma
Because on Windows static data is always addressed with absolute addresses. This is just a convention, but one which is completely adhered to.Quote:
Originally Posted by phantomotap
On Linux it actually works differently and uses a mechanism that involves this idiom:
In actuality there is more involved, but this is what I meant by using a single instruction because that's how Windows does things.Code:call @1
@1:
pop ebx # get PC
mov eax, [ebx+offset] # index relative to PC
EDIT: Also, I was trying to highlight the fact that x86 doesn't have direct support for PC-relative addressing. Sure, you can achieve it but then again you can achieve almost anything you want if you work at it.
Ah, I see. I didn't realize you were literally talking about something that would work in "real life" with the Windows program loader. I was just thinking a viable x86 strategy.Quote:
Because on Windows static data is always addressed with absolute addresses.
Soma