What the value of the e_shstrndx field in elf mean?
In my file its value is 4. How can I get the section headers names in the file using this constant?
Related
This is for a relocatable ELF object file, not fully-linked ELF or ELF shared library.
Currently if there is a program such as main.c:
int main() {
foo();
return 0;
}
and compile with gcc -c main.c it will generate a main.o.
I want to replace the call to foo with fool or food (a longer name) after the object file is already created.
Because currently the relocatable ELF will be broken if we extend past the length 3 of foo.
How can I do this?
I want to replace the call to foo with fool or food (a longer name) after the object file is already created.
This is quite possible, but far from trivial.
First, you need to copy the .symtab section to the end of the file, and append the desired string food\0 to it.
Second, you need to update the section table and replace the offset and length of the original .symtab with the offset and size if the section added in previous step.
Last, you need to find the symbol (in the .symtab section) and update its st_name with the offset of the food string added in the first step.
And that's all there is to it.
I have an OBJ with 2c1 sections. How can I dump the header of only section 101?
dumpbin /HEADERS /SECTION:101 file.obj gives me the whole list. The same thing as dumpbin /HEADERS file.obj with the added line:
LINK : warning LNK4039: section '101' specified with /SECTION option does not exist
But it does:
SECTION HEADER #101
.rdata name
0 physical address
0 virtual address
10 size of raw data
11A9C file pointer to raw data (00011A9C to 00011AAB)
0 file pointer to relocation table
0 file pointer to line numbers
0 number of relocations
0 number of line numbers
40301040 flags
Initialized Data
COMDAT; sym= EP_Commands
4 byte align
Read Only
The /SECTION documentation doesn't help. Geoff say's the section name is case sensitive. I have tried decimal numbers. I have tried hex numbers. I have tried #101. I have tried sect101.
You are using section number instead of section name. Here is the command-line to get the details of only the above section you have mentioned in your question:
dumpbin /HEADERS /SECTION:.rdata file.obj
Is there anyway i can look into the values of a structure after compilation? objdump -td gives the function definitions and only the address where the structure is stored. The problem is i am getting a wrong address for one of the threads/functions in a structure when i run a program. The target mcu is lpc1347 (ARM Cortex-m3).
objdump parses object files (products of the compiler), which are relocatable (not executable) ELF files. At this stage, there is no such notion as the memory address these compiled pieces will run at.
You have the following possibilities:
Link your *.obj files into the final non-stripped (-g passed to compiler) executable ELF image and parse it using readelf.
Generate the linker map file by adding -Wl,-Map,file.map to your LDFLAGS and see the output sections and addresses your data is located at in the map file.
Use a debugger/gdb.
In an LD linker script I have the following fragment in the SECTIONS section:
. = (__BUFFER_LOCATION_);
BUFFER . : { } > EXTERNAL_MEM
where __BUFFER_LOCATION_ is defined to some address and EXTERNAL_MEM is defined in the MEMORY section.
In the C program, I have a global buffer declared as:
char outbuf[4096] __attribute__((section("BUFFER")));
It can be seen that the linker script does not mention any input section named BUFFER, but the output section is named as such.
When compiling the program I see that the linker placed the buffer in the supposed address (BUFFER_LOCATION), although the input section was not defined in the LDF. When I remove the attribute from the source, the buffer is placed in a completely different address.
So, I assume that by default, an output-section-command of type "input section description" adds the output section's name to the input sections list implicitly, unless defined somewhere else. However, reading the manual, I could not find a description of such behaviour.
Did I miss something, or is it an "undocumented feature"?
Yes, an output section will automatically match input sections with the same name, unless a different output section mentions them explicitly.
This is documented under Orphan Sections (emphasis mine):
Orphan sections are sections present in the input files which are not explicitly placed into the output file by the linker script. The
linker will still copy these sections into the output file by either
finding, or creating a suitable output section in which to place the
orphaned input section.
If the name of an orphaned input section exactly matches the name of
an existing output section, then the orphaned input section will be
placed at the end of that output section.
If there is no output section with a matching name then new output
sections will be created...
Assume the following:
Elf_Section_Header *sectionHeaderTable //points to the start of a ELF section header table
Elf_Section_Header *symtabHeader //points to the start of the symtab section header
Why doesn't the following point me to the associated string table section header?
Elf_Section_Header *strTabSectionHeader = (Elf_Section_Header *)((char *)sectionHeaderTable + (symtabHeader->strtab_index));
strTabSectionHeader->type == SHT_STRTAB is equal to false
How should I point to the associated string table section header?
Presumably the ->strtab_index struct member is referring to the sh_name member of the symbol table header (as named in the ELF spec).
This is actually an index within the section header string table section, not the location of a string table.
String tables are stored in their own sections. The section header string table in particular is located by the e_shstrndx member of the ELF header. This is an index into the section header table - thus sectionHeaderTable[elf_header->e_shstrndx] is likely what you want (the section header for the section header string table).
Each Binary generally contains three String tables -
1. .dynstr
2. .shstrtab
3. .strtab
IN the above question we are concerned with .shstrtab which when expanded stands for - Section Header STRing TABle. Upon reading the ELF header we find the following field in ELF header - e_shstrndx. This is the index where we can find .shstrtab. Following formula can be used to calculate how it will be done -
offset = ((elfHdr.e_shstrndx)*elfHdr.e_shentsize)+elfHdr.e_shoff
Meaning of each parameter -
elfHdr.e_shstrndx = index where we can find .shstrtab
elfHdr.e_shentsize = Size of each Section Header
elfHdr.e_shoff = Offset at which section header starts.
PLease comment if u need more details
A section header’s sh_name member holds an index into the section header string table section, as designated by the e_shstrndx member of the ELF header.
ELF Specification