I was analyzing format of one executable file, I found Base relocation table in image_optional_header, what is this base relocation table?
The relocation table is a lookup table that lists all parts of the PE file that need patching when the file is loaded at a non-default base address.
Here is the microsoft spec on PE files:
https://github.com/tpn/pdfs/blob/master/Microsoft%20Portable%20Executable%20and%20Common%20Object%20File%20Format%20Specification%20-%201999%20(pecoff).doc
And a good article: http://web.archive.org/web/20200806080448/http://www.csn.ul.ie/~caolan/pub/winresdump/winresdump/doc/pefile2.html
There are 2 relocation tables. COFF relocation table, which is only present in .obj files and contains the addresses of the rip-relative offset bytes of all instructions accessing local/extern linkage symbols in the object file, paired with an index into the symbol table to the entry for the symbol it references. The COFF relocation table for the section is pointed to by the section header for the section in the section table after the COFF header.
typedef struct {
unsigned long r_vaddr; /* address of relocation */
unsigned long r_symndx; /* symbol we're adjusting for */
unsigned short r_type; /* type of relocation */
} RELOC; //COFF relocation table entry
For a symbol that is not defined in the object file, it will be an *UNDEF* entry in the symbol table (the section number will be of the *UNDEF* section), and the offset from the *UNDEF* section is always 0. For a symbol that is defined, it will have a correct section and a correct offset into the section in the symbol table, and if the symbol name can't be inlined in the string table entry, it points to the index in the string table for the name of the symbol. The linker will use these section+offsets for the static symbols and the section+offsets of the extern symbols it includes to calculate the correct offset from the end of r_vaddr to the section+offset of the symbol. It then replaces the address at r_vaddr with that value i.e. it replaces call -1 or call 0 with the correct relative value
The base relocation table is for runtime and is built in the .obj file and merged into the final .exe and is pointed to by BaseRelocationTable in the PE header and is usually in .reloc. If the image is loaded at an address that isn't the ImageBase the linker selected and placed in the PE header, then the patches in the base relocation table need to be applied. The base relocation table is made up of base relocation blocks and each block describes a 4 KiB page. The block header contains the RVA of the page and the size of the block structure. The rest of the block contains an array of 2 byte fields where the first 4 bits of the 2 bytes indicates the relocation type and the latter 12 bits indicates the offset from the page RVA to which the relocation needs to be applied. This will be the offset to an address field in an instruction. To relocate, the loader just calculates the difference between ImageBase and the real base address of the process in the PEB and adds/subtracts it from the address. There won't be many base relocations because most of the symbols in the code use register indirect rip-relative addressing (for mov and dllimport calls) and direct relative addressing (for regular calls). In COFF objects, both relative and absolute addresses need to be relocated, in the PE executable, only absolute addresses need relocations.
typedef struct _IMAGE_BASE_RELOCATION {
DWORD VirtualAddress; //Page RVA
DWORD SizeOfBlock;
WORD TypeOffset[1];
} IMAGE_BASE_RELOCATION; //base relocation table
Related
When I compile my Delphi project and instruct the compiler to create a memory mapping file (*.map) it contains a description of the used memory segments at the top of the file.
Example:
Start Length Name Class
0001:00401000 00475600H .text CODE
0002:00877000 00004998H .itext ICODE
0003:0087C000 00030410H .data DATA
0004:008AD000 00009170H .bss BSS
0005:00000000 00000278H .tls TLS
When looking at the PE section table docs only ".text" and the other sections except for ".itext" is listed there.
What is the purpose of that ".itext" segment and how does it differ from ".text"? Is it some Delphi/Borland/Embarcadero-specific extension?
The itext segments (with Class = ICODE) resemble the initialization sections of the linked units.
I'm trying to make COSMIC compiler allocate a struct at a specific address in the memory (0x5420). I added the following lines in my C code (where CAN_TypeDef is a typedef struct):
#pragma section [mycan]
CAN_TypeDef CAN;
#pragma section []
In the IDE (STVD), I created a new section named Can inside which I created a new section named .mycan.
When I build the code in STVD, a linker error appears saying:
#error clnk Debug\can.lkf:1 bad address (0x5420) for zero page symbol _CAN
In the above picture, it is clear that Can and Zero Page are two different segments. What can be the cause of this error and how can I solve it?
I don't know the STM8, but I think I found it. In the STVD documentation I read:
Global variables
When the category is set to General , you can use
the Global Variables list box to specify the default location of
global variables:
In Zero Page: This is the default option.
In Data: Specifies to place global variables in the first 64Kbytes of
memory.
So the compiler assumes all global data sitting in the zero page and the addresses are just eight bit wide. Only the linker sees that the section .mycan is not in the zero page and you get an error. I would try #near CAN_TypeDef CAN; or simply extern CAN_TypeDef CAN #5420; without creating your own section.
How is SizeOfImage in the PE optional header computed?
Trying to learn the PE format, I've come across the SizeOfImage field in the optional header.
To quote the documentation:
The size (in bytes) of the image, including all headers, as the image
is loaded in memory. It must be a multiple of SectionAlignment.
However, I've experienced that if I set this field wrongly, then the executable won't run and an error 193 (badly formatted excutable) is displayed:
How do I compute the SizeOfImage field, and why won't an executable run if its set wrong (e.g. the executable runs if it's set to 0x00003000 but not 0x00004000 or 0x00002000)?
The safest way that I know of is to loop through each section and find the section to be loaded last in memory (i.e. the highest address). You can almost always assume this is the last section and just skip directly to that section if you trust your PE file (such as if you are using a standard linker, etc). You begin with calculating the end-of-data pointer of that section as follows:
pEndOfLastSection = pLastSection->VirtualAddress + pLastSection->Misc.VirtualSize + pOptionalHeader->ImageBase
pEndOfLastSection now represents the end of the actual section's data (as it exists in the file, padded to file alignment, but not padded to memory alignment) and doesn't include any padding the loader must add to ensure the section fits exactly within the granularity of the memory section alignment.
Despite the other fields that might seem to store the end of the section rounded up to the next nearest "memory" alignment, you must you must perform this calculation yourself on the pEndOfLastSection pointer. I wrote the following function which so far has worked for my purposes:
//
// peRoundUpToAlignment() - rounds dwValue up to nearest dwAlign
//
DWORD peRoundUpToAlignment(DWORD dwAlign, DWORD dwVal)
{
if (dwAlign)
{
//do the rounding with bitwise operations...
//create bit mask of bits to keep
// e.g. if section alignment is 0x1000 1000000000000
// we want the following bitmask 11111111111111111111000000000000
DWORD dwMask = ~(dwAlign-1);
//round up by adding full alignment (dwAlign-1 since if already aligned we don't want anything to change),
// then mask off any lower bits
dwVal = (dwVal + dwAlign-1) & dwMask;
}
return(dwVal);
} //peRoundUpToAlignment()
Now take your pEndOfLastSecion and pass it to the rounding function as follows:
//NOTE: we are rounding to memory section alignment, not file
pEndOfLastSectionMem = peRoundUpToAlignment(pOptionalHeader->SectionAlignment,pEndOfLastSection)
Now you have a "simulated" pointer to the end of the PE file as it would be loaded in memory. NOTE: the end pointers calculated above actually point 1 byte past the last byte of the last section; this allows you to subtract them from their base to get the size. Once you have the end pointer of the last section as it would be loaded in memory, you can subtract this from the loader base and get the size of the PE file as it should be loaded in memory, and this size is obviously the same regardless of where the loader might relocate the PE file:
uCalcSizeOfFile = pEndOfLastSectionMem - pOptionalHeader->ImageBase
Unless the image has been tampered with, the calculation of uCalcSizeOfFile above should be equal to the pOptionalHeader->SizeOfImage field.
My application has a number of modules that each require some variables to be stored in off-chip non-volatile memory. To make the reading and writing of these easier, I'm trying to collect them together into a contiguous region of RAM, to that the NVM driver can address a single block of memory when communicating with the NVM device.
To achieve this, I have created a custom linker script containing the following section definition.
.nvm_fram :
{
/* Include the "nvm_header" input section first. */
*(.nvm_header)
/* Include all other input sections prefixed with "nvm_" from all modules. */
*(.nvm_*)
/* Allocate a 16 bit variable at the end of the section to hold the CRC. */
. = ALIGN(2);
_gld_NvmFramCrc = .;
LONG(0);
} > data
_GLD_NVM_FRAM_SIZE = SIZEOF(.nvm_fram);
The data region is defined in the MEMORY section using the standard definition provided by Microchip for the target device.
data (a!xr) : ORIGIN = 0x1000, LENGTH = 0xD000
One example of a C source file which attempts to place its variables in this section is the NVM driver itself. The driver saves a short header structure at teh beginning of the NVM section so that it can verify the content of the NVM device before loading it into RAM. No linker error reported for this variable.
// Locate the NVM configuration in the non-volatile RAM section.
nvm_header_t _nvmHeader __attribute__((section(".nvm_header")));
Another module that has variables to store in the .nvm_fram section is the communications (CANopen) stack. This saves the Module ID and bitrate in NVM.
// Locate LSS Slave configuration in the non-volatile RAM section.
LSS_slave_config_t _slaveConfig __attribute__((section(".nvm_canopen"))) =
{ .BitRate = DEFAULT_BITRATE, .ModuleId = DEFAULT_MODULEID };
Everything compiles nicely, but when the linker runs, the following error stops the build.
elf-ld.exe: Link Error: attributes for input section '.nvm_canopen' conflict with
output section '.nvm_fram'
It's important that the variables can be initialised with values by the crt startup, as shown by the _slaveConfig declaration above, in case the NVM driver cannot load them from the NVM device (it's blank, or the software version has changed, etc.). Is this what's causing the attributes mismatch?
There are several questions here and on the Microchip forums, which relate to accessing symbols that are defined in the linker script from C. Most of these concern values in the program Flash memory and how to access them from C; I know how to do this. There is a similar question, but this doesn't appear to address the attributes issue, and is a little confusing due to being specific to a linker for a different target processor.
I've read the Microchip linker manual and various GCC linker documents online, but can't find the relevant sections because I don't really understand what the error means and how it relates to my code. What are the 'input and output section attributes', where are they specified in my code, and how do I get them to match eachother?
The problem is due to the _nvmHeader variable not having an initial value assigned to it in the C source, but the _slaveConfig variable does.
This results in the linker deducing that the .nvm_fram output section is uninitialised (nbss) from the .nvm_header input section attributes. So, when it enconters initialised data in the .nvm_canopen input section from the _slaveConfig variable, there is a mismatch in the input section attributes: .nvm_fram is for uninitialised data, but .nvm_canopen contains initialised data.
The solution is to ensure that all variables that are to be placed in the .nvm_fram output section are given initial values in the C source.
// Type used to hold metadata for the content of the NVM.
typedef struct
{
void* NvmBase; // The original RAM address.
uint16_t NvmSize; // The original NVM section size.
} nvm_header_t;
// The linker supplies the gld_NVM_FRAM_SIZE symbol as a 'number'.
// This is represented as the address of an array of unspecified
// length, so that it cannot be implicitly dereferenced, and cast
// to the correct type when used.
extern char GLD_NVM_FRAM_SIZE[];
// The following defines are used to convert linker symbols into values that
// can be used to initialise the _nvmHeader structure below.
#define NVM_FRAM_BASE ((void*)&_nvmHeader)
#define NVM_FRAM_SIZE ((uint16_t)GLD_NVM_FRAM_SIZE)
// Locate the NVM configuration in the non-volatile RAM section.
nvm_header_t _nvmHeader __attribute__((section(".nvm_header"))) =
{
.NvmBase = NVM_FRAM_BASE, .NvmSize = NVM_FRAM_SIZE
};
The answer is therefore that the output section attributes may be determined partly by the memory region in which the section is to be located and also by the attributes of the first input section assigned to it. Initialised and uninitialised C variables have different input section attributes, and therefore cannot be located within the same output section.
On Linux, when linking I can specify any virtual address for a section:
ld -Ttext 0x10000000 -Tdata 0x20000000 foo.o -o foo
But I don't see such option for Windows' link.exe.
Is it possible to specify PE section start addresses somehow?
MinGW ld can put the sections at arbitrary addresses. Dumpbin and disassemblers can handle it without problem.
But it seems Windows does not accept anything but the default address: if you try to set it to a different value Windows will say "not a valid Win32 application".
The base address must be 0x400000 or 0x1000000.
And the .text section must be at 0x401000 or 0x1001000.
Also it seems no gaps allowed between the sections. If I try to place the .data section to 0x403000 instead of 0x402000, then Windows is unable to load it...
(I maybe wrong, or mingw ld is buggy...)
When using GCC, this page explains how to define variables at absolute addresses (including mentioning the section in which they should reside) : https://mcuoneclipse.com/2012/11/01/defining-variables-at-absolute-addresses-with-gcc/
The idea I use here is to put the variable with a special section
name, and then place it in the linker file at an absolute address.
unsigned char __attribute__((section (".myBufSection"))) buf[128]
__attribute__ ((aligned (512)));
With this, my variable will be put into a section named
‘.myBufSection’, and it will be aligned on a 512 address boundary.
The next step is to place that section at an address in the linker file.
SECTIONS
{
/* placing my named section at given address: */
.myBufBlock 0x20000000 :
{
KEEP(*(.myBufSection)) /* keep my variable even if not referenced */
} > m_data
/* other placements follow here... */
}
PS: Another method is mentioned in How can I declare a variable at an absolute address with GCC?
PS 2: Another related (alas unanswered) question is this : How to place a variable at a given absolute address in memory (with Visual C++)