aboutsummaryrefslogtreecommitdiff
path: root/llvm/tools/llvm-objcopy/ELF/Object.cpp
AgeCommit message (Collapse)AuthorFilesLines
2022-02-17[llvm-objcopy][NFC] Move core implementation of llvm-objcopy into separate ↵Alexey Lapshin1-2826/+0
library. This patch moves core implementation of llvm-objcopy into Object library (http://lists.llvm.org/pipermail/llvm-dev/2020-September/145075.html). The functionality for parsing input options is left inside tools/llvm-objcopy. The interface of ObjCopy library: ObjCopy/ELF/ELFObjcopy.h ``` Error executeObjcopyOnIHex(const CopyConfig &Config, MemoryBuffer &In, Buffer &Out); Error executeObjcopyOnRawBinary(const CopyConfig &Config, MemoryBuffer &In, Buffer &Out); Error executeObjcopyOnBinary(const CopyConfig &Config, object::ELFObjectFileBase &In, Buffer &Out); ``` ObjCopy/COFF/COFFObjcopy.h ``` Error executeObjcopyOnBinary(const CopyConfig &Config, object::COFFObjectFile &In, Buffer &Out); ``` ObjCopy/MachO/MachOObjcopy.h ``` Error executeObjcopyOnBinary(const CopyConfig &Config, object::MachOObjectFile &In, Buffer &Out); ``` ObjCopy/wasm/WasmObjcopy.h ``` Error executeObjcopyOnBinary(const CopyConfig &Config, object::WasmObjectFile &In, Buffer &Out); ``` Differential Revision: https://reviews.llvm.org/D88827
2022-02-03[llvm-objcopy][COFF] Implement --update-sectionAlex Brachet1-1/+1
Reviewed By: jhenderson, MaskRay Differential Revision: https://reviews.llvm.org/D118189
2021-12-14[llvm-objcopy] Fix handling of MIPS64 little endian filesSimon Atanasyan1-13/+23
MIPS64 little endian target has a "special" encoding of `r_info` relocation record field. Instead of one 64-bit little endian number, it is a little endian 32-bit number followed by a 32-bit big endian number. For correct reading and writing such fields we must provide information about target machine into the corresponding routine. This patch does this for the `llvm-objcopy` tool and fix handling of MIPS64 little endian files. The bug was reported in the issue #52647. Differential Revision: https://reviews.llvm.org/D115635
2021-11-16[llvm-objcopy] Add --update-sectionLeonard Chan1-0/+42
This is another attempt at D59351 which attempted to add --update-section, but with some heuristics for adjusting segment/section offsets/sizes in the event the data copied into the section is larger than the original size of the section. We are opting to not support this case. GNU's objcopy was able to do this because the linker and objcopy are tightly coupled enough that segment reformatting was simpler. This is not the case with llvm-objcopy and lld where they like to be separated. This will attempt to copy data into the section without changing any other properties of the parent segment (if the section is part of one). Differential Revision: https://reviews.llvm.org/D112116
2021-09-24[llvm-objcopy][NFC] Add a helper method RelocationSectionBase::getNamePrefix()Igor Kudrin1-0/+11
Refactor handleArgs() to use that method. Differential Revision: https://reviews.llvm.org/D110350
2021-08-12[llvm-objcopy][ELF] Avoid reordering section headersIgor Kudrin1-37/+67
As for now, llvm-objcopy sorts section headers according to the offsets of the sections in the input file. That can corrupt section references in the dynamic symbol table because it is a loadable section and as such is not updated by the tool. Even though the section references are not required for loading the binary correctly, they are still handy for a user who analyzes the file. While the patch removes global reordering of section headers, it layouts the sections in the same way as before, i.e. according to their original offsets. All that helps the output file to resemble the input better. Note that the patch removes sorting SHT_GROUP sections to the start of the list, which was introduced in D62620 in order to ensure that they come before the group members, along with the corresponding test. The original issue was caused by the sorting of section headers, so dropping the sorting also resolves the issue. Differential Revision: https://reviews.llvm.org/D107653
2021-08-03[llvm-objcopy] IHexELFBuilder::addDataSections - fix evaluation ordering ↵Simon Pilgrim1-5/+8
static analyzer warning As detailed on https://pvs-studio.com/en/blog/posts/cpp/0771/ and raised on D62583, the SecNo++ increment is not guaranteed to occur before the second use of SecNo in the same addSection() call. This patch pulls out the increment (just for clarity) and replaces the second use of SecNo with a constant zero value (we're using stable_sort so the value isn't critical). Differential Revision: https://reviews.llvm.org/D107273
2021-07-26[llvm-objcopy] Fix section group flag read/write when operating on a ↵Fangrui Song1-2/+3
cross-endian object file
2021-07-26[llvm-objcopy] Drop GRP_COMDAT if the group signature is localizedFangrui Song1-0/+6
See [GRP_COMDAT group with STB_LOCAL signature](https://groups.google.com/g/generic-abi/c/2X6mR-s2zoc) objcopy PR: https://sourceware.org/bugzilla/show_bug.cgi?id=27931 GRP_COMDAT deduplication is purely based on the signature symbol name in ld.lld/GNU ld/gold. The local/global status is not part of the equation. If the signature symbol is localized by --localize-hidden or --keep-global-symbol, the intention is likely to make the group fully localized. Drop GRP_COMDAT to suppress deduplication. Reviewed By: jhenderson Differential Revision: https://reviews.llvm.org/D106782
2021-06-22[llvm-objcopy] Fix some namespace style issuesFangrui Song1-12/+14
https://llvm.org/docs/CodingStandards.html#use-namespace-qualifiers-to-implement-previously-declared-functions Reviewed By: jhenderson Differential Revision: https://reviews.llvm.org/D104693
2021-06-16[llvm-objcopy] Make ihex writer similar to binary writerFangrui Song1-19/+2
There is no need to differentiate whether `UseSegments` is true or false. Unifying the cases makes the behavior closer to BinaryWriter. This improves compatibility with objcopy because SHF_ALLOC sections not in a PT_LOAD will not be skipped. Such cases are usually erroneous input, though. Reviewed By: jhenderson Differential Revision: https://reviews.llvm.org/D104186
2021-06-12llvm-objcopy: fix section size truncation/extension when dumping sectionsDavid Blaikie1-1/+1
Since this only comes up with inputs containing sections at least 4GB large (I guess I could use a bzero section or something, so the input file doesn't have to be 4GB, but even then the output file would have to be 4GB, right?) I've skipped testing this. If there's a nice way to test this without needing 4GB inputs or output files. The subtlety here is demonstrated by this code: struct t { operator uint64_t(); }; static_assert(std::is_same_v<int, decltype(std::declval<bool>() ? 0 : std::declval<t>())>); static_assert(std::is_same_v<uint64_t, decltype(std::declval<bool>() ? 0 : std::declval<uint64_t>())>); Because of this difference, the original source code was getting an int type (truncating the actual size) and then extending it again, resulting in bogus values (I haven't thought through this hard enough to explain why the resulting value was 0xffff... - sign extension, possible UB, but in any case it's the wrong answer - in this particular case I was looking at that resulted in a size so large that we couldn't open a file large enough to write to and ended up with a rather vague: error: 'file_name.o': Invalid argument
2021-06-12[llvm-objcopy] Exclude empty sections in IHexWriter outputIan McIntyre1-1/+2
IHexWriter was evaluating a section's physical address when deciding if that section should be written to an output. This approach does not account for a zero-sized section that has the same physical address as a sized section. The behavior varies from GNU objcopy, and may result in a HEX file that does not include all program sections. The IHexWriter now excludes zero-sized sections when deciding what should be written to the output. This affects the contents of the writer's `Sections` collection; we will not try to insert multiple sections that could have the same physical address. The behavior seems consistent with GNU objcopy, which always excludes empty sections, no matter the address. The new test case evaluates the IHexWriter behavior when provided a variety of empty sections that overlap or append a filled section. See the input file's comments for more information. Given that test input, and the change to the IHexWriter, GNU objcopy and llvm-objcopy produce the same output. Reviewed By: jhenderson, MaskRay, evgeny777 Differential Revision: https://reviews.llvm.org/D101332
2021-05-12Fixed llvm-objcopy to add correct symbol table for ELF with program headers.Alex Orlov1-0/+4
This fixes the following bugs: https://bugs.llvm.org/show_bug.cgi?id=43935 Reviewed By: jhenderson Differential Revision: https://reviews.llvm.org/D102258
2021-05-05[llvm-objcopy][ELF] --only-keep-debug: set offset/size of segments with no ↵Fangrui Song1-10/+11
sections to zero PR50160: we currently ignore non-PT_PHDR segments with no sections, not accounting for its p_offset and p_filesz: this can cause an out-of-bounds write in `writeSegmentData` if the p_offset+p_filesz is larger than the total file size. This can be fixed by setting p_offset=p_filesz=0. The logic nicely unifies with the logic added in D90897. Reviewed By: jhenderson, rupprecht Differential Revision: https://reviews.llvm.org/D101560
2021-03-10[llvm-objcopy][NFC] replace class Buffer/MemBuffer/FileBuffer with streams.Alexey Lapshin1-30/+65
During D88827 it was requested to remove the local implementation of Memory/File Buffers: // TODO: refactor the buffer classes in LLVM to enable us to use them here // directly. This patch uses raw_ostream instead of Buffers. Generally, using streams could allow us to reduce memory usages. No need to load all data into the memory - the data could be streamed through a smaller buffer. Thus, this patch uses raw_ostream as an interface for output data: Error executeObjcopyOnBinary(CopyConfig &Config, object::Binary &In, raw_ostream &Out); Note 1. This patch does not change the implementation of Writers so that data would be directly stored into raw_ostream. This is assumed to be done later. Note 2. It would be better if Writers would be implemented in a such way that data could be streamed without seeking/updating. If that would be inconvenient then raw_ostream could be replaced with raw_pwrite_stream to have a possibility to seek back and update file headers. This is assumed to be done later if necessary. Note 3. Current FileOutputBuffer allows using a memory-mapped file. The raw_fd_ostream (which could be used if data should be stored in the file) does not allow us to use a memory-mapped file. Memory map functionality could be implemented for raw_fd_ostream: It is possible to add resize() method into raw_ostream. class raw_ostream { void resize(uint64_t size); } That method, implemented for raw_fd_ostream, could create a memory-mapped file. The streamed data would be written into that memory file then. Thus we would be able to use memory-mapped files with raw_fd_ostream. This is assumed to be done later if necessary. Differential Revision: https://reviews.llvm.org/D91028
2021-03-05[llvm-objcopy] Fix crash for binary input files with non-ascii namesJames Henderson1-2/+3
The code was using the standard isalnum function which doesn't handle values outside the non-ascii range. Switching to using llvm::isAlnum instead ensures we don't provoke undefined behaviour, which can in some cases result in crashes. Reviewed by: MaskRay Differential Revision: https://reviews.llvm.org/D97663
2021-03-04[llvm-objcopy/strip] Fix off-by-one error in SYMTAB_SHNDX need checkJames Henderson1-1/+3
The check for whether an extended symbol index table was required dropped the first SHN_LORESERVE sections from the sections array before checking whether the remaining sections had symbols. Unfortunately, the null section header is not present in this list, so the check was skipping the first section that might be important. If that section contained a symbol, and no subsequent ones did, the .symtab_shndx section would not be emitted, leading to a corrupt object. Also consolidate and expand test coverage in the area to cover this bug and other aspects of the SYMTAB_SHNDX section. Reviewed by: alexshap, MaskRay Differential Revision: https://reviews.llvm.org/D97661
2021-02-01[llvm-objcopy] -O binary: consider SHT_NOBITS sections to be emptyPatrick Oppenlander1-1/+1
This is consistent with BFD objcopy. Previously llvm objcopy would allocate space for SHT_NOBITS sections often resulting in enormous binary files. New test case (binary-paddr.test %t6). Reviewed By: jhenderson, MaskRay Differential Revision: https://reviews.llvm.org/D95569
2021-01-19[llvm] Use llvm::any_of (NFC)Kazu Hirata1-2/+2
2020-11-11[llvm-objcopy][ELF] Try fixing non-determinism of Segment::firstSectionFangrui Song1-0/+1
2020-11-11[llvm-objcopy] --only-keep-debug: place zero-size segment according to its ↵Fangrui Song1-2/+9
parent segment Alternative to D74755. sectionWithinSegment() treats an empty section as having a size of 1. Due to the rule, an empty .tdata will not be attributed to an empty PT_TLS. (The empty p_align=64 PT_TLS is for Android Bionic's TCB compatibility (ELF-TLS). See https://reviews.llvm.org/D62055#1507426) Currently --only-keep-debug will not layout a segment with no section (layoutSegmentsForOnlyKeepDebug()), thus p_offset of PT_TLS can go past the end of the file. The strange p_offset can trigger validation errors for subsequent tools, e.g. llvm-objcopy errors when reading back the separate debug file (readProgramHeaders()). This patch places such an empty segment according to its parent segment. This special cases works for the empty PT_TLS used in Android. For a non-empty segment, it should have at least one non-empty section and will be handled by the normal code. Note, p_memsz PT_LOAD is rejected by both Linux and FreeBSD. Reviewed By: jhenderson Differential Revision: https://reviews.llvm.org/D90897
2020-10-06[llvm-objcopy][NFC] fix style issues reported by clang-format.Alexey Lapshin1-15/+12
2020-10-02[llvm-objcopy][NFC] refactor error handling. part 3.Alexey Lapshin1-278/+566
Remove usages of special error reporting functions(error(), reportError()). Errors are reported as Expected<>/Error returning values. This part is for ELF subfolder of llvm-objcopy. Testing: check-all. Differential Revision: https://reviews.llvm.org/D87987
2020-09-15[lib/Object] - Refine interface of ELFFile<ELFT>. NFCI.Georgii Rymar1-15/+15
`ELFFile<ELFT>` has many methods that take pointers, though they assume that arguments are never null and hence could take references instead. This patch performs such clean-up. Differential revision: https://reviews.llvm.org/D87385
2020-07-05[llvm-objcopy] Fix crash when removing symbol table at same time as adding a ↵Georgy Komarov1-21/+28
symbol This patch resolves crash that occurs when user wanted to remove all symbols and add a brand new one using: ``` llvm-objcopy -R .symtab --add-symbol foo=1234 in.o out.o ``` Before these changes the symbol table internally being null when adding new symbols. For now we will regenerate symtab in this case. This fixes: https://bugs.llvm.org/show_bug.cgi?id=43930 Reviewed By: jhenderson Differential Revision: https://reviews.llvm.org/D82935
2020-07-02Fix typo and check commit access.Sameer Arora1-2/+2
2020-06-29[llvm-objcopy] Emit error if removing symtab referenced by group sectionGeorgy Komarov1-14/+26
SHT_GROUP sections contain a reference to a symbol indicating their "signature" symbol. The symbol table containing this symbol is referred to by the group section's sh_link field. If llvm-objcopy is instructed to remove the symbol table, it will emit an error. This fixes https://bugs.llvm.org/show_bug.cgi?id=46153. Reviewed By: jhenderson, Higuoxing Differential Revision: https://reviews.llvm.org/D82274
2020-06-24[Hexagon][llvm-objcopy] Add missing check for SHN_HEXAGON_SCOMMON_1Sid Manning1-0/+1
Differential Revision: https://reviews.llvm.org/D82484
2020-05-29[llvm-objcopy][ELF] Fix removing a group member.Igor Kudrin1-1/+9
When a group member is removed, the corresponding record in the SHT_GROUP section has to be deleted. This fixes PR46064. Differential Revision: https://reviews.llvm.org/D80568
2020-05-29[llvm-objcopy][ELF] Fix removing SHT_GROUP sections.Igor Kudrin1-0/+9
When a SHT_GROUP section is removed, but other sections of the group are kept, the SHF_GROUP flag of these sections should be dropped, otherwise the resulting ELF file will be malformed. Differential Revision: https://reviews.llvm.org/D80511
2020-05-03[llvm-objcopy] Avoid invalid Sec.Offset after D79229Fangrui Song1-4/+4
To avoid undefined behavior caught by -fsanitize=undefined on binary-paddr.test void SectionWriter::visit(const Section &Sec) { if (Sec.Type != SHT_NOBITS) // Sec.Contents is empty while Sec.Offset may be out of bound llvm::copy(Sec.Contents, Out.getBufferStart() + Sec.Offset); }
2020-05-01[llvm-objcopy] -O binary: skip empty sectionsFangrui Song1-6/+7
After SHF_ALLOC sections are ordered by LMA: * If initial sections are empty, GNU objcopy skips their contents while we emit leading zeros. (binary-paddr.test %t4) * If trailing sections are empty, GNU objcopy skips their contents while we emit trailing zeros. (binary-paddr.test %t5) This patch matches GNU objcopy's behavior. Linkers don't keep p_memsz PT_LOAD segments. Such empty sections would not have a containing PT_LOAD and `Section::ParentSegment` might be null if linkers fail to optimize the file offsets (lld D79254). In particular, without D79254, the arm Linux kernel's multi_v5_defconfig depends on this behavior: in `vmlinux`, an empty .text_itcm is mapped at a very high address (0xfffe0000) but the kernel does not expect `objcopy -O binary` to create a very large `arch/arm/boot/Image` (0xfffe0000-0xc0000000 ~= 1GiB). See https://bugs.llvm.org/show_bug.cgi?id=45632 Reviewed By: jhenderson Differential Revision: https://reviews.llvm.org/D79229
2020-04-27[llvm-objcopy] Don't specialize the all zero p_paddr caseFangrui Song1-36/+0
Spotted by https://reviews.llvm.org/D74755#1998673 > it looks like OrderedSegments in the function is only used to set the physical address to the virtual address when there are no physical addresses set amongst these sections. I believe this behavior was copied from https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=6ffd79000b45e77b3625143932ffbf781b6aecab (2008-05) The commit was made for some corner cases of very old linkers. This special rule does not seem useful and remove it can allow us to delete a large chunk of code. Reviewed By: jhenderson, jakehehrlich Differential Revision: https://reviews.llvm.org/D78786
2020-04-14[ADT/STLExtras.h] - Add llvm::is_sorted wrapper and update callers.Georgii Rymar1-2/+1
It can be used to avoid passing the begin and end of a range. This makes the code shorter and it is consistent with another wrappers we already have. Differential revision: https://reviews.llvm.org/D78016
2020-02-10Revert "Remove redundant "std::move"s in return statements"Bill Wendling1-3/+3
The build failed with error: call to deleted constructor of 'llvm::Error' errors. This reverts commit 1c2241a7936bf85aa68aef94bd40c3ba77d8ddf2.
2020-02-10Remove redundant "std::move"s in return statementsBill Wendling1-3/+3
2020-01-28Make llvm::StringRef to std::string conversions explicit.Benjamin Kramer1-1/+1
This is how it should've been and brings it more in line with std::string_view. There should be no functional change here. This is mostly mechanical from a custom clang-tidy check, with a lot of manual fixups. It uncovers a lot of minor inefficiencies. This doesn't actually modify StringRef yet, I'll do that in a follow-up.
2019-12-15[llvm-objcopy][ELF] -O binary: use LMA instead of sh_offset to decide where ↵Fangrui Song1-23/+13
to write section contents .text sh_address=0x1000 sh_offset=0x1000 .data sh_address=0x3000 sh_offset=0x2000 In an objcopy -O binary output, the distance between two sections equal their LMA differences (0x3000-0x1000), instead of their sh_offset differences (0x2000-0x1000). This patch changes our behavior to match GNU. This rule gets more complex when the containing PT_LOAD has p_vaddr!=p_paddr. GNU objcopy essentially computes sh_offset-p_offset+p_paddr for each candidate section, and removes the gap before the first address. Added tests to binary-paddr.test to catch the compatibility problem. Reviewed By: jhenderson Differential Revision: https://reviews.llvm.org/D71035
2019-11-18Fix cppcheck shadow variable warning. NFC.Simon Pilgrim1-3/+3
2019-11-05[llvm-objcopy][ELF] Implement --only-keep-debugFangrui Song1-12/+97
--only-keep-debug produces a debug file as the output that only preserves contents of sections useful for debugging purposes (the binutils implementation preserves SHT_NOTE and non-SHF_ALLOC sections), by changing their section types to SHT_NOBITS and rewritting file offsets. See https://sourceware.org/gdb/onlinedocs/gdb/Separate-Debug-Files.html The intended use case is: ``` llvm-objcopy --only-keep-debug a a.dbg llvm-objcopy --strip-debug a b llvm-objcopy --add-gnu-debuglink=a.dbg b ``` The current layout algorithm is incapable of deleting contents and shrinking segments, so it is not suitable for implementing the functionality. This patch adds a new algorithm which assigns sh_offset to sections first, then modifies p_offset/p_filesz of program headers. It bears a resemblance to lld/ELF/Writer.cpp. Reviewed By: jhenderson, jakehehrlich Differential Revision: https://reviews.llvm.org/D67137
2019-11-05[llvm-objcopy][ELF] Add OriginalType & OriginalFlagsFangrui Song1-3/+3
`llvm::objcopy::elf::*Section::classof` matches Type and Flags, yet Type and Flags are mutable (by setSectionFlagsAndTypes and upcoming --only-keep-debug feature). Add OriginalType & OriginalFlags to be used in classof, to prevent classof results from changing. Reviewed By: jakehehrlich, jhenderson, alexshap Differential Revision: https://reviews.llvm.org/D69739
2019-10-31[llvm-objcopy] --add-symbol: address post-commit reviews of D69093Fangrui Song1-17/+18
* Improve comments. * Reorder the assignment to Obj.SectionNames before the symbol table creation code. Add a test. Reviewed By: grimar Differential Revision: https://reviews.llvm.org/D69526
2019-10-30[llvm-objcopy] - Do not crash on object that has relocations but no symbol ↵Georgii Rymar1-5/+16
table. It was revealed by D69260. Tool crashed when scanned relocations in a object without a symbol table. This patch teaches it either to handle such objects (when relocations does not use symbols we do not need a symbol table to proceed) or to show an appropriate error otherwise. Differential revision: https://reviews.llvm.org/D69304
2019-10-17[llvm-objcopy] --add-symbol: fix crash if SHT_SYMTAB does not existFangrui Song1-10/+31
Exposed by D69041. If SHT_SYMTAB does not exist, ELFObjcopy.cpp:handleArgs will crash due to a null pointer dereference. for (const NewSymbolInfo &SI : Config.ELF->SymbolsToAdd) { ... Obj.SymbolTable->addSymbol( Fix this by creating .symtab and .strtab on demand in ELFBuilder<ELFT>::readSections, if --add-symbol is specified. Reviewed By: grimar Differential Revision: https://reviews.llvm.org/D69093 llvm-svn: 375105
2019-09-25[NFC] Add { } to silence compiler warning [-Wmissing-braces].Huihui Zhang1-1/+1
/local/mnt/workspace/huihuiz/llvm-comm-git-2/llvm-project/llvm/lib/Object/MachOObjectFile.cpp:2731:7: warning: suggest braces around initialization of subobject [-Wmissing-braces] "i386", "x86_64", "x86_64h", "armv4t", "arm", "armv5e", ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ { 1 warning generated. /local/mnt/workspace/huihuiz/llvm-comm-git-2/llvm-project/llvm/lib/Target/AMDGPU/AMDGPURegisterBankInfo.cpp:355:46: warning: suggest braces around initialization of subobject [-Wmissing-braces] return addMappingFromTable<1>(MI, MRI, { 0 }, Table); ^ {} 1 warning generated. /local/mnt/workspace/huihuiz/llvm-comm-git-2/llvm-project/llvm/tools/llvm-objcopy/ELF/Object.cpp:400:57: warning: suggest braces around initialization of subobject [-Wmissing-braces] static constexpr std::array<uint8_t, 4> ZlibGnuMagic = {'Z', 'L', 'I', 'B'}; ^~~~~~~~~~~~~~~~~~ { } 1 warning generated. llvm-svn: 372811
2019-09-14[llvm-objcopy] Ignore -B --binary-architecture=Fangrui Song1-2/+2
GNU objcopy documents that -B is only useful with architecture-less input (i.e. "binary" or "ihex"). After D67144, -O defaults to -I, and -B is essentially a NOP. * If -O is binary/ihex, GNU objcopy ignores -B. * If -O is elf*, -B provides the e_machine field in GNU objcopy. So to convert a blob to an ELF, `-I binary -B i386:x86-64 -O elf64-x86-64` has to be specified. `-I binary -B i386:x86-64 -O elf64-x86-64` creates an ELF with its e_machine field set to EM_NONE in GNU objcopy, but a regular x86_64 ELF in elftoolchain elfcopy. Follow the elftoolchain approach (ignoring -B) to simplify code. Users that expect their command line portable should specify -B. Reviewed By: jhenderson Differential Revision: https://reviews.llvm.org/D67215 llvm-svn: 371914
2019-09-07[llvm-objcopy] Rename SHOffset (e_shoff) field to SHOff. NFCFangrui Song1-6/+6
Similar to D67254. `struct Elf*_Shdr` has a field `sh_offset`. Rename SHOffset to SHOff to avoid confusion. llvm-svn: 371281
2019-09-04[llvm-objcopy] Add objcopy::elf::Object::allocSections to simplify loops on ↵Fangrui Song1-20/+8
SHF_ALLOC sections Reviewed By: jhenderson Differential Revision: https://reviews.llvm.org/D67142 llvm-svn: 370860
2019-09-04[llvm-objcopy] Rename variable names "Section" to "Sec". NFCFangrui Song1-66/+60
"Section" can refer to the type llvm::objcopy::elf::Section or the variable name. Rename it to "Sec" for clarity. "Sec" is already used a lot, so this change improves consistency as well. Also change `auto` to `const SectionBase` for readability. Reviewed By: grimar Differential Revision: https://reviews.llvm.org/D67143 llvm-svn: 370852
generated by cgit v1.1 at 2025-10-20 23:02:35 +0000