Relate TLS sections to TLS segments only
Output Section to Segment mapping
Add test that verifies that get_symbols_num() returns increased value after add_symbol()
check that stream is big enough, accounting for overflow
Add arm relocation types
Just reformatting
Add test for segment size change bug
Add yet another "Elf in a library" image
Fix: 32 typos
Upgrade GitHub actions
Check file offset doesn't exceed file size
Add RISC-V relocation types
Validate size of entries before accessing members
Fix warning shown up with clang compiler
Change a comment
Proper ignore resource files for CPack
Unused images are moved to a separate folder
Move artworks folder to 'doc' directory
Increase the library version number
The workflow is used by another project
Add workflow_dispatch
Permit workflow_call
Move to actions/checkout@v4
Add Windows-2019
Add 2 Mac OSes
Add Mac builds
Add c_compiler
Advance Google Test commit #
Remove C compiler settings
Exclude cl.exe build from Ubuntu-20-04
Add older Ubuntu OS version
Update c-cpp.yml
Green title
Fix formatting
The library artwork added
Remove unnecessary files in 'test' directory
Change relocation type to R_X86_64_32
Experimental change of section table alignment to 16
Rename 'free_data' test
Best way to overlay segment/section data
Best way to overlay segment/section data
I have applied the changes in commit #e078644. The tests are still passing and "write" examples are functional. So, let it be the new default value
I do see the changes inside the correspondence above. Changing the alignment from 4 to 16 did the work. I am wondering why this value is chosen and on base of what information the library can select appropriate value. I have modified the value to 16 and all tests are still passing. The question is whether it should be the default value
Hi Steve, Unfortunately, I didn't find your Push Request and/or user name in GitHub. So, I could not review the submission
Implement free_data() for sections too
Add segment's free_data() description to the doc
Refactor the last commit
Use more portable function memchr()
C++17 refactoring
Use c++17 standard
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?...
Hi, it looks like I missed all the action. Please submit your changes. If possible, please do it as a GitHub pull request: 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();...
Thank you. My utility takes 2 file arguments. As a self test, I specified an exact copy of the reader vmlinux file for the writer. Interestingly, the writer (patched) file is written 4 bytes shorter than the original vmlinux. There are a number of diffs. I would expect the patched file to be the same as the original since it was an exact copy.
Thank you for your enquiry. Please let me couple of days to look at this
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();...
Best way to overlay segment/section data
Remove unnecessary initialization that causes GCC warning
Use CodeQL Actions v2
Minor refactoring
Update elfio.hpp
Increase version number for future release
Rewrite append_data() to call insert_data()
Add missed implementation function for insert_data()
Add insert_data() to section
Switch to a newer 'googletest' archive
VSCode settings update
Generate output of compile commands during generation
Remove dispersed 'noexcept' specifier
Revert the change of the previous commit
tests: allow using system gtest copy
Don't build tests by default. Set ELFIO_BUILD_TESTS=ON
Make more const variables
Add tests for lazy load
Implement 'lazy' load for sections
'noexept' added to upper level API members
Add 'lazy' load for own opened streams
Initial attempt for lazy load - segment loading
Lazy load segment data - load data upon request
Remove redundant member initialization
Use const referencies in set_xxx arguments
Remove output to std::cerr
Generilize the section compression calls
Externalize zlib dependency
Add support for writing RPL/RPX
fix mismatched allocator warning
Add support for reading Wii U RPX/RPL