3

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, why is there for relocation table, as we would anyways be using RVA's which would be relative to the new base??

user1232138
  • 5,451
  • 8
  • 37
  • 64

2 Answers2

3

The point is that the code doesn't access the globals (global variables and function addresses) via RVA or whats-or-ever. They're accessed by their absolute address. And this address should be changed in case the executable was not loaded at its preferred address.

The relocation table consists exactly of those places. It's a table of all the places that should be adjusted by the difference of the actual base address and the preferred one.

BTW, EXEs, in contrast to DLLs usually don't contain relocation tables. This is because they're the first module to be mapped into the address space, hence they may always be loaded at their preferred address. The situation is different for DLLs, which usually do contains relocation tables.

P.S. In Windows 7 EXE may contain relocation table in case they prefer to be loaded at random address. It's a security feature (pitiful IMHO)

Edit:

Should be mentioned that function addresses are not always accessed by their absolute value. On x86 branching instructions (such as jmp, call and etc.) have a "short" format which works with the relative offset. Such places don't neet to be mentioned in relocation table.

valdo
  • 12,632
  • 2
  • 37
  • 67
  • "the code doesn't access the globals (global variables and function addresses) via RVA or whats-or-ever" How is that possible?? Doesn't the global variables go into the data section, which itself is at a relative offset from the base – user1232138 Mar 14 '12 at 16:59
  • Global variables may be stored in the EXE data section. So what? Still they have an absolute virtual address. Just compile a sample program accessing a global variable, and check the code with the debugger. You'll see that the linker puts the direct address there – valdo Mar 14 '12 at 17:15
  • Are there any specific reasons for this?? I mean why can't all the global variables be at Relative Offsets too?? Wouldn't that make the lives of linker writers, a whole lot easier?? – user1232138 Mar 14 '12 at 17:22
  • maybe. But the point is the executable image size and performance, not the life quality of the "linker writers". If you have a privilege to know from the beginning the absolute address of a global - why not use this? Relocations may occur, but they are relatively rare – valdo Mar 14 '12 at 17:35
  • 2
    The x86 CPU does not have a "relative offset from PC" addressing mode. – Raymond Chen Mar 15 '12 at 01:56
  • The *pitiful* security feature although does not withstand all attacks all the time, still saves quite some time, money, traffic and headache just because there are many programs using this feature and running on many computers. Better than nothing. Simple probability. – Alexey Frunze Mar 15 '12 at 06:20
  • @valdo: "EXEs in contrast to DLLs usually don't contain relocation tables". That certainly *used* to be the case. Nowadays, the ASLR exploit-protection mechanism relies on EXEs being relocatable, and failing to provide relocation tables forces your EXE to be non-ASLR-able, and hence much more suceptible to exploitation by naughty cyber-criminals. – SecurityMatt Mar 30 '12 at 00:40
  • @RaymondChen: But the x86-64 does. – SecurityMatt Mar 30 '12 at 00:41
  • @SecurityMatt The question was a general one, not one specific to x86-64. Relocations are needed in general because some processors do not have a "relative offset from PC" addressing mode. And you still need them for global pointers and jump tables (switches). – Raymond Chen Mar 30 '12 at 19:32
1

For an EXE file there is no need for the relocation table because the executable image is always loaded at its preferred address. The relocation table can safely be stripped.

David Heffernan
  • 601,492
  • 42
  • 1,072
  • 1,490