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
Related
Why do some linux kernel section names use a single . and others use two
For example .data..page_aligned and .data..init_task vs .data.unlikely and .data.once
Does the number of . have a specific meaning
Thanks
I have read the ld and kernel documentation and not found any information
Section name .data..init_task consists from 3 parts:
Prefix .data.
Delimiter ..
Name of the subsection .init_task.
Since the name of the subsection starts with dot, the section name contains the sequence of two dots.
The section name .data.unlikely consists from 3 parts too, but the name of the subsection - unlikely - is not started with dot.
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 am trying to implement custom loader with linker script and elf file.
I can successfully load PT_LOAD type program header which can contain .text, .data section in it.
But what I really want is loading each data and text "section" separately and page-aligned.
I could successfully locate each section included in the PT_LOAD program header so far.
However, I need this section be page-aligned(0x1000) to load it separated page.
How can I locate all section in the specific program header be page-aligned ?
make each section page aligned.
e.g. get each section check if it is equal to page size (e.g 0x1000)
if its more than that of your page round it to page size.
Have some routine similar to listed below.
#define ROUND_TO_PAGE(x,y) (((x) + (y)) & (~(y)))
x = your section
y = page_size - 1 & page_size = 4096 (i.e.yours - 0x1000)
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?
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...