Steve Clevenger

I've merged my ELFIO Release 3.11 work to a local ELFIO clone of https://github.com/serge1/ELFIO and created a branch. Unfortunately, I couldn't compile the new source base with my compiler and cmake settings. My inexperience with cmake made my early builds of ELFIO problematic. As I recall, there were a number of changes required to get it to work. I used the headers only and didn't even try to build a library. Also, do you need to add a permission for me to push a branch to https://github.com/serge1/ELFIO?...

The problem is the alignmentError calculated in layout_section_table(). My ELFCLASS64 file requires a 16 byte alignment. The following implementation (hack) will provide the expected result. The ELF specification states the the section header alignment is based off the sh_addralign value. "Only 0 and positive integral powers of 2 are currently allowed. A value of 0 or 1 indicates no address alignment constraints." As I understand it, the first section is SHT_NULL. The first (code) section in my file...

Hi Serge, I narrowed this down to a single load/save operation without any patching. If a vmlinux ELF file is loaded with ELFIO load, then immediately saved with ELFIO save, the vmlinux copy is shorter by 4 bytes with the other differences attributable only to the save operation. The host system is AARCH64 Fedora Linux. How can I help? I have only GDB command-line debug available to me (decades old technology), and this C++ is heavily templated.

Here's another data point. It may/may not be meaningful. If I dump the ELF header on each file after the patch operation, the first difference I see is the value of the e_shoff field (section header table offset) has shifted 4 bytes in the patched file. I would expect no difference here. [root@sut01sys-b212 build]# hexdump -C -n 64 ~/linux/vmlinux 00000000 7f 45 4c 46 02 01 01 00 00 00 00 00 00 00 00 00 |.ELF............| 00000010 03 00 b7 00 01 00 00 00 00 00 00 08 00 80 ff ff |................|...

Here's another data point. It may/may not be meaningful. If I dump the ELF header on each file after the patch operation, the first difference I see is the value of the e_shoff filed (section header table offset) has shifted 4 bytes in the patched file. I would expect no difference here. [root@sut01sys-b212 build]# hexdump -C -n 64 ~/linux/vmlinux 00000000 7f 45 4c 46 02 01 01 00 00 00 00 00 00 00 00 00 |.ELF............| 00000010 03 00 b7 00 01 00 00 00 00 00 00 08 00 80 ff ff |................|...

Here's a code snippet. I loop through the executable sections of the file to be patched, then read the corresponding segment code. The challenge is patching (overlaying) the code correctly. bool b_patched = false; for (int i = 0; i < writer.sections.size(); ++i) { section* p_sec = writer.sections[i]; Elf64_Addr section_addr = p_sec->get_address(); Elf_Xword section_sz = p_sec->get_size(); if ((p_sec->get_type() & SHT_PROGBITS) && (p_sec->get_flags() & SHF_EXECINSTR)) { Elf_Half seg_num = reader.segments.size();...

Here's a code snippet. I loop through the executable sections of the file to be patched, then read the corresponding segment code. The challenge is patching (overlaying) the code correctly. bool b_patched = false; for (int i = 0; i < writer.sections.size(); ++i) { section* p_sec = writer.sections[i]; Elf64_Addr section_addr = p_sec->get_address(); Elf_Xword section_sz = p_sec->get_size(); if ((p_sec->get_type() & SHT_PROGBITS) && (p_sec->get_flags() & SHF_EXECINSTR)) { Elf_Half seg_num = reader.segments.size();...

Here's a code snippet. I loop through the executable sections of the file to be patched, then read the corresponding segment code. The challenge is patching (overlaying) the code correctly. bool b_patched = false; for (int i = 0; i < writer.sections.size(); ++i) { section* p_sec = writer.sections[i]; Elf64_Addr section_addr = p_sec->get_address(); Elf_Xword section_sz = p_sec->get_size(); if ((p_sec->get_type() & SHT_PROGBITS) && (p_sec->get_flags() & SHF_EXECINSTR)) { Elf_Half seg_num = reader.segments.size();...