aboutsummaryrefslogtreecommitdiff
path: root/llvm/lib/Object/ELF.cpp
AgeCommit message (Collapse)AuthorFilesLines
2021-03-08[M68k](4/8) MC layer and object file supportMin-Yih Hsu1-0/+7
- Add the M68k-specific MC layer implementation - Add ELF support for M68k - Add M68k-specifc CC and reloc TODO: Currently AsmParser and disassembler are not implemented yet. Please use this bug to track the status: https://bugs.llvm.org/show_bug.cgi?id=48976 Authors: myhsu, m4yers, glaubitz Differential Revision: https://reviews.llvm.org/D88390
2021-01-28Use DataExtractor to decode SLEB128 in android_relas.Rahman Lavaee1-35/+23
A simple refactoring patch which let us use `DataExtractor::getSLEB128` rather than using a lambda function. Differential Revision: https://reviews.llvm.org/D95158
2021-01-05[llvm] Use llvm::lower_bound and llvm::upper_bound (NFC)Kazu Hirata1-5/+4
2020-12-16[llvm-readelf/obj] - Handle out-of-order PT_LOADs better.Georgii Rymar1-1/+13
This is https://bugs.llvm.org/show_bug.cgi?id=45698. Specification says that "Loadable segment entries in the program header table appear in ascending order, sorted on the p_vaddr member." Our `toMappedAddr()` relies on this condition. This patch adds a warning when the sorting order of loadable segments is wrong. In this case we force segments sorting and that allows `toMappedAddr()` to work as expected. Differential revision: https://reviews.llvm.org/D92641
2020-10-08Introduce and use a new section type for the bb_addr_map section.Rahman Lavaee1-0/+1
This patch lets the bb_addr_map (renamed to __llvm_bb_addr_map) section use a special section type (SHT_LLVM_BB_ADDR_MAP) instead of SHT_PROGBITS. This would help parsers, dumpers and other tools to use the sh_type ELF field to identify this section rather than relying on string comparison on the section name. Reviewed By: jhenderson Differential Revision: https://reviews.llvm.org/D88199
2020-09-15[lib/Object] - Refine interface of ELFFile<ELFT>. NFCI.Georgii Rymar1-3/+3
`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-09-07[ELF] Add a new e_machine value EM_CSKY and add some CSKY relocation typesZi Xuan Wu1-0/+9
This is the split part of D86269, which add a new ELF machine flag called EM_CSKY and related relocations. Some target-specific flags and tests for csky can be added in follow-up patches later. Differential Revision: https://reviews.llvm.org/D86610
2020-08-05[llvm-readobj] - Make decode_relrs() don't return Expected<>. NFCI.Georgii Rymar1-1/+1
The `decode_relrs` helper is declared as: `Expected<std::vector<Elf_Rel>> decode_relrs(Elf_Relr_Range relrs) const;` it never returns an error though and hence can be simplified to return a vector. Differential revision: https://reviews.llvm.org/D85302
2020-07-20[llvm-readobj] - Refactor how the code dumps relocations.Georgii Rymar1-10/+9
There is a strange "feature" of the code: it handles all relocations as `Elf_Rela`. For handling `Elf_Rel` it converts them to `Elf_Rela` and passes `bool IsRela` to specify the real type everywhere. A related issue is that the `decode_relrs` helper in lib/Object has to return `Expected<std::vector<Elf_Rela>>` because of that, though it could return a vector of `Elf_Rel`. I think we should just start using templates for relocation types, it makes the code cleaner and shorter. This patch does it. Differential revision: https://reviews.llvm.org/D83871
2020-05-28[VE] Implements minimum MC layer for VE (3/4)Kazushi (Jam) Marukawa1-0/+7
Summary: Define ELF binary code for VE and modify code where should use this new code. Depends on D79544. Reviewed By: jhenderson Differential Revision: https://reviews.llvm.org/D79545
2020-05-11[Object] Remove unused variable after D79560. NFC.Xing GUO1-3/+0
2020-05-08[Object] Remove unneeded check in ELFFile<ELFT>::dynamicEntries().Xing GUO1-4/+0
Check for `DynSecSize % sizeof(Elf_Dyn) != 0` is unneeded in this context. 1. If the .dynamic section is acquired from program headers, the .dynamic section is "cut off" by ``` makeArrayRef(..., Phdr.p_filesz / sizeof(Elf_Dyn)); DynSeSize = Phdr.p_filesz; ``` 2. If the .dynamic section is acquired from section headers, the .dynamic section is checked in `getSectionContentsAsArray<Elf_Dyn>(&Sec)`. Reviewed By: MaskRay Differential Revision: https://reviews.llvm.org/D79560
2020-03-31[RISCV] ELF attribute section for RISC-V.Kai Wang1-0/+3
Leverage ARM ELF build attribute section to create ELF attribute section for RISC-V. Extract the common part of parsing logic for this section into ELFAttributeParser.[cpp|h] and ELFAttributes.[cpp|h]. Differential Revision: https://reviews.llvm.org/D74023
2020-03-27[llvm-readobj] - Fix a crash when DT_STRTAB is broken.Georgii Rymar1-1/+12
We might have a crash scenario when we have an invalid DT_STRTAB value that is larger than the file size. I've added a test case to demonstrate. Differential revision: https://reviews.llvm.org/D76706
2019-12-24[llvm-readobj] - Remove an excessive helper for printing dynamic tags.Georgii Rymar1-1/+1
This removes the `getTypeString` from readeobj source because it almost duplicates the existent method: `ELFFile<ELFT>::getDynamicTagAsString`. Side effect: now it prints "<unknown:>0xHEXVALUE" instead of "(unknown)" for unknown values. llvm-readelf before this patch printed: ``` 0x0000000012345678 (unknown) 0x8765432187654321 0x000000006abcdef0 (unknown) 0x9988776655443322 0x0000000076543210 (unknown) 0x5555666677778888 ``` and now it prints: ``` 0x0000000012345678 (<unknown:>0x12345678) 0x8765432187654321 0x000000006abcdef0 (<unknown:>0x6abcdef0) 0x9988776655443322 0x0000000076543210 (<unknown:>0x76543210) 0x5555666677778888 ``` GNU reaedlf prints different thing: ``` 0x0000000012345678 (<unknown>: 12345678) 0x8765432187654321 0x000000006abcdef0 (Operating System specific: 6abcdef0) 0x9988776655443322 0x0000000076543210 (Processor Specific: 76543210) 0x5555666677778888 ``` I am not sure we want to follow GNU here. Even if we do, it should be separate patch probably. The new output looks better and closer to GNU anyways, and the code is a bit simpler. Differential revision: https://reviews.llvm.org/D71835
2019-09-06[llvm-readobj][yaml2obj] Support SHT_LLVM_SYMPART, SHT_LLVM_PART_EHDR and ↵Fangrui Song1-0/+2
SHT_LLVM_PART_PHDR See http://lists.llvm.org/pipermail/llvm-dev/2019-February/130583.html and D60242 for the lld partition feature. This patch: * Teaches yaml2obj to parse the 3 section types. * Teaches llvm-readobj/llvm-readelf to dump the 3 section types. There is no test for SHT_LLVM_DEPENDENT_LIBRARIES in llvm-readobj. Add it as well. Reviewed By: thakis Differential Revision: https://reviews.llvm.org/D67228 llvm-svn: 371157
2019-07-05[Object/ELF.h] - Improve error reporting.George Rimar1-2/+7
The errors coming from ELF.h are usually not very useful because they are uninformative. This patch is a first step to improve the situation. I tested this patch with a run of check-llvm and found that few messages are untested. In this patch, I did not add more tests but marked all such cases with a "TODO" comment. For all tested messages I extended the error text to provide more details (see test cases changed). Differential revision: https://reviews.llvm.org/D64014 llvm-svn: 365183
2019-06-04[AArch64][ELF][llvm-readobj] Add support for BTI and PAC dynamic tagsPeter Smith1-0/+10
ELF for the 64-bit Arm Architecture defines two processor-specific dynamic tags: DT_AARCH64_BTI_PLT 0x70000001, d_val DT_AARCH64_PAC_PLT 0x70000003, d_val These presence of these tags indicate that PLT sequences have been protected using Branch Target Identification and Pointer Authentication respectively. The presence of both indicates that the PLT sequences have been protected with both Branch Target Identification and Pointer Authentication. This patch adds the tags and tests for llvm-readobj and yaml2obj. As some of the processor specific dynamic tags overlap, this patch splits them up, keeping their original default value if they were not previously mentioned explicitly in a switch case. Differential Revision: https://reviews.llvm.org/D62596 llvm-svn: 362493
2019-05-29Add IR support, ELF section and user documentation for partitioning feature.Peter Collingbourne1-0/+1
The partitioning feature was proposed here: http://lists.llvm.org/pipermail/llvm-dev/2019-February/130583.html This is mostly just documentation. The feature itself will be contributed in subsequent patches. Differential Revision: https://reviews.llvm.org/D60242 llvm-svn: 361923
2019-05-17[ELF] Implement Dependent Libraries FeatureBen Dunbobbin1-0/+1
This patch implements a limited form of autolinking primarily designed to allow either the --dependent-library compiler option, or "comment lib" pragmas ( https://docs.microsoft.com/en-us/cpp/preprocessor/comment-c-cpp?view=vs-2017) in C/C++ e.g. #pragma comment(lib, "foo"), to cause an ELF linker to automatically add the specified library to the link when processing the input file generated by the compiler. Currently this extension is unique to LLVM and LLD. However, care has been taken to design this feature so that it could be supported by other ELF linkers. The design goals were to provide: - A simple linking model for developers to reason about. - The ability to to override autolinking from the linker command line. - Source code compatibility, where possible, with "comment lib" pragmas in other environments (MSVC in particular). Dependent library support is implemented differently for ELF platforms than on the other platforms. Primarily this difference is that on ELF we pass the dependent library specifiers directly to the linker without manipulating them. This is in contrast to other platforms where they are mapped to a specific linker option by the compiler. This difference is a result of the greater variety of ELF linkers and the fact that ELF linkers tend to handle libraries in a more complicated fashion than on other platforms. This forces us to defer handling the specifiers to the linker. In order to achieve a level of source code compatibility with other platforms we have restricted this feature to work with libraries that meet the following "reasonable" requirements: 1. There are no competing defined symbols in a given set of libraries, or if they exist, the program owner doesn't care which is linked to their program. 2. There may be circular dependencies between libraries. The binary representation is a mergeable string section (SHF_MERGE, SHF_STRINGS), called .deplibs, with custom type SHT_LLVM_DEPENDENT_LIBRARIES (0x6fff4c04). The compiler forms this section by concatenating the arguments of the "comment lib" pragmas and --dependent-library options in the order they are encountered. Partial (-r, -Ur) links are handled by concatenating .deplibs sections with the normal mergeable string section rules. As an example, #pragma comment(lib, "foo") would result in: .section ".deplibs","MS",@llvm_dependent_libraries,1 .asciz "foo" For LTO, equivalent information to the contents of a the .deplibs section can be retrieved by the LLD for bitcode input files. LLD processes the dependent library specifiers in the following way: 1. Dependent libraries which are found from the specifiers in .deplibs sections of relocatable object files are added when the linker decides to include that file (which could itself be in a library) in the link. Dependent libraries behave as if they were appended to the command line after all other options. As a consequence the set of dependent libraries are searched last to resolve symbols. 2. It is an error if a file cannot be found for a given specifier. 3. Any command line options in effect at the end of the command line parsing apply to the dependent libraries, e.g. --whole-archive. 4. The linker tries to add a library or relocatable object file from each of the strings in a .deplibs section by; first, handling the string as if it was specified on the command line; second, by looking for the string in each of the library search paths in turn; third, by looking for a lib<string>.a or lib<string>.so (depending on the current mode of the linker) in each of the library search paths. 5. A new command line option --no-dependent-libraries tells LLD to ignore the dependent libraries. Rationale for the above points: 1. Adding the dependent libraries last makes the process simple to understand from a developers perspective. All linkers are able to implement this scheme. 2. Error-ing for libraries that are not found seems like better behavior than failing the link during symbol resolution. 3. It seems useful for the user to be able to apply command line options which will affect all of the dependent libraries. There is a potential problem of surprise for developers, who might not realize that these options would apply to these "invisible" input files; however, despite the potential for surprise, this is easy for developers to reason about and gives developers the control that they may require. 4. This algorithm takes into account all of the different ways that ELF linkers find input files. The different search methods are tried by the linker in most obvious to least obvious order. 5. I considered adding finer grained control over which dependent libraries were ignored (e.g. MSVC has /nodefaultlib:<library>); however, I concluded that this is not necessary: if finer control is required developers can fall back to using the command line directly. RFC thread: http://lists.llvm.org/pipermail/llvm-dev/2019-March/131004.html. Differential Revision: https://reviews.llvm.org/D60274 llvm-svn: 360984
2019-03-13[ELF] Fix GCC8 warnings about "fall through", NFCIJonas Hahnfeld1-0/+3
Add break statements in Object/ELF.cpp since the code should consider the generic tags for Hexagon, MIPS, and PPC. Add a test (copied from llvm-readobj) to show that this works correctly (earlier versions of this patch would have asserted). The warnings in X86ELFObjectWriter.cpp are actually false-positives since the nested switch() handles all possible values and returns in all cases. Make this explicit by adding llvm_unreachable's. Differential Revision: https://reviews.llvm.org/D58837 llvm-svn: 356037
2019-03-02[llvm-objdump] Should print unknown d_tag in hex formatXing GUO1-3/+3
Summary: Currently, `llvm-objdump` prints "unknown" instead of d_tag value in hex format. Because getDynamicTagAsString returns "unknown" rather than empty string. Reviewers: grimar, jhenderson Reviewed By: jhenderson Subscribers: rupprecht, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D58763 llvm-svn: 355262
2019-02-21[ObjectYAML] Support SHT_MIPS_DWARF section type flagFangrui Song1-1/+1
Also reorder SHT_MIPS_DWARF and SHT_MIPS_ABIFLAGS in Object/ELF.cpp. The test will be added by D58457. llvm-svn: 354563
2019-01-19Update the file headers across all of the LLVM projects in the monorepoChandler Carruth1-4/+3
to reflect the new license. We understand that people may be surprised that we're moving the header entirely to discuss the new license. We checked this carefully with the Foundation's lawyer and we believe this is the correct approach. Essentially, all code in the project is now made available by the LLVM project under our new license, so you will see that the license headers include that license only. Some of our contributors have contributed code under our old license, and accordingly, we have retained a copy of our old license notice in the top-level files in each project and repository. llvm-svn: 351636
2018-12-14[Object] Rename getRelrRelocationType to getRelativeRelocationTypeFangrui Song1-2/+2
Summary: The two utility functions were added in D47919 to support SHT_RELR. However, these are just relative relocations types and are't necessarily be named Relr. Reviewers: phosek, dberris Reviewed By: dberris Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D55691 llvm-svn: 349133
2018-11-15[MSP430] Add MC layerAnton Korobeynikov1-0/+7
Reapply r346374 with the fixes for modules build. Original summary: This change implements assembler parser, code emitter, ELF object writer and disassembler for the MSP430 ISA. Also, more instruction forms are added to the target description. Patch by Michael Skvortsov! llvm-svn: 346948
2018-11-08Revert "[MSP430] Add MC layer"Davide Italiano1-7/+0
This commit broke the module buildbots. Error: lib/Target/MSP430/MSP430GenAsmMatcher.inc:1027:1: error: redundant namespace 'llvm' [-Wmodules-import-nested-redundant] ^ llvm-svn: 346410
2018-11-08[MSP430] Add MC layerAnton Korobeynikov1-0/+7
Summary: This change implements assembler parser, code emitter, ELF object writer and disassembler for the MSP430 ISA. Also, more instruction forms are added to the target description. Reviewers: asl Reviewed By: asl Subscribers: pftbest, krisb, mgorny, llvm-commits Differential Revision: https://reviews.llvm.org/D53661 llvm-svn: 346374
2018-08-15llvm-readobj: Fix addend in relocations for android packed formatPeter Collingbourne1-9/+6
If a relocation group doesn't have the RELOCATION_GROUP_HAS_ADDEND_FLAG set, then this implies the group's addend equals zero. In this case android packed format won't encode an explicit addend delta, instead we need to set Addend, the "previous addend" variable, to zero by ourself. Patch by Yi-Yo Chiang! Differential Revision: https://reviews.llvm.org/D50601 llvm-svn: 339799
2018-07-25[llvm-objdump] Add dynamic section printing to private-headers optionPaul Semel1-0/+138
Differential Revision: https://reviews.llvm.org/D49016 llvm-svn: 337902
2018-07-17MC: Implement support for new .addrsig and .addrsig_sym directives.Peter Collingbourne1-0/+1
Part of the address-significance tables proposal: http://lists.llvm.org/pipermail/llvm-dev/2018-May/123514.html Differential Revision: https://reviews.llvm.org/D47744 llvm-svn: 337328
2018-07-16[WebAssembly] Remove ELF file support.Sam Clegg1-9/+0
This support was partial and temporary. Now that we have wasm object file support its no longer needed. Differential Revision: https://reviews.llvm.org/D48744 llvm-svn: 337222
2018-06-28[llvm-readobj] Add experimental support for SHT_RELR sectionsJake Ehrlich1-0/+127
This change adds experimental support for SHT_RELR sections, proposed here: https://groups.google.com/forum/#!topic/generic-abi/bX460iggiKg Definitions for the new ELF section type and dynamic array tags, as well as the encoding used in the new section are all under discussion and are subject to change. Use with caution! Author: rahulchaudhry Differential Revision: https://reviews.llvm.org/D47919 llvm-svn: 335922
2018-06-02[MC] Add assembler support for .cg_profile.Michael J. Spencer1-0/+1
Object FIle Representation At codegen time this is emitted into the ELF file a pair of symbol indices and a weight. In assembly it looks like: .cg_profile a, b, 32 .cg_profile freq, a, 11 .cg_profile freq, b, 20 When writing an ELF file these are put into a SHT_LLVM_CALL_GRAPH_PROFILE (0x6fff4c02) section as (uint32_t, uint32_t, uint64_t) tuples as (from symbol index, to symbol index, weight). Differential Revision: https://reviews.llvm.org/D44965 llvm-svn: 333823
2018-01-30CodeGen: support an extension to pass linker options on ELFSaleem Abdulrasool1-0/+1
Introduce an extension to support passing linker options to the linker. These would be ignored by older linkers, but newer linkers which support this feature would be able to process the linker. Emit a special discarded section `.linker-option`. The content of this section is a pair of strings (key, value). The key is a type identifier for the parameter. This allows for an argument free parameter that will be processed by the linker with the value being the parameter. As an example, `lib` identifies a library to be linked against, traditionally the `-l` argument for Unix-based linkers with the parameter being the library name. Thanks to James Henderson, Cary Coutant, Rafael Espinolda, Sean Silva for the valuable discussion on the design of this feature. llvm-svn: 323783
2017-12-19Silence a bunch of implicit fallthrough warningsAdrian Prantl1-0/+1
llvm-svn: 321114
2017-11-03Revert r317046, "Object: Move some code from ELF.h into ELF.cpp."Peter Collingbourne1-263/+0
This change resulted in a measured 1.5-2% perf regression linking chrome. llvm-svn: 317371
2017-10-31Object: Move some code from ELF.h into ELF.cpp.Peter Collingbourne1-0/+263
Differential Revision: https://reviews.llvm.org/D39271 llvm-svn: 317046
2017-10-27ELF: Add support for emitting dynamic relocations in the Android relocation ↵Peter Collingbourne1-0/+2
packing format. The Android relocation packing format is a more compact format for dynamic relocations in executables and DSOs that is based on delta encoding and SLEBs. An overview of the format can be found in the Android source code: https://android.googlesource.com/platform/bionic/+/refs/heads/master/tools/relocation_packer/src/delta_encoder.h This patch implements relocation packing using that format. This implementation uses a more intelligent algorithm for compressing relative relocations than Android's own relocation packer. As a result it can generally create smaller relocation sections than that packer. If I link Chromium for Android targeting ARM32 I get a .rel.dyn of size 174693 bytes, as compared to 371832 bytes with gold and the Android packer. Differential Revision: https://reviews.llvm.org/D39152 llvm-svn: 316775
2017-10-25llvm-readobj: Add support for reading relocations in the Android packed format.Peter Collingbourne1-0/+90
This is in preparation for testing lld's upcoming relocation packing feature (D39152). I have verified that this implementation correctly unpacks the relocations from a Chromium DSO built with gold and the Android relocation packer for ARM32 and ARM64. Differential Revision: https://reviews.llvm.org/D39272 llvm-svn: 316543
2017-09-13[ARC] Prepare the implementation of relocation for LLDLeslie Zhai1-0/+8
Reviewers: ruiu, kparzysz, petecoup, rafael Reviewed By: kparzysz Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D37556 llvm-svn: 313109
2017-06-14MC, Object: Reserve a section type, SHT_LLVM_ODRTAB, for the ODR table.Peter Collingbourne1-0/+1
This is part of the ODR checker proposal: http://lists.llvm.org/pipermail/llvm-dev/2017-June/113820.html Per discussion on the gnu-gabi mailing list [1] the section type range 0x6fff4c00..0x6fff4cff is reserved for LLVM. [1] https://sourceware.org/ml/gnu-gabi/2017-q2/msg00030.html Differential Revision: https://reviews.llvm.org/D33978 llvm-svn: 305407
2017-06-07Move Object format code to lib/BinaryFormat.Zachary Turner1-17/+17
This creates a new library called BinaryFormat that has all of the headers from llvm/Support containing structure and layout definitions for various types of binary formats like dwarf, coff, elf, etc as well as the code for identifying a file from its magic. Differential Revision: https://reviews.llvm.org/D33843 llvm-svn: 304864
2017-05-02Add llvm::object::getELFSectionTypeName().Rafael Espindola1-3/+63
This is motivated by https://reviews.llvm.org/D32488 where I am trying to add printing of the section type for incompatible sections to LLD error messages. This patch allows us to use the same code in llvm-readobj and LLD instead of duplicating the function inside LLD. Patch by Alexander Richardson! llvm-svn: 301921
2017-04-24[Object] Fix some Clang-tidy modernize and Include What You Use warnings; ↵Eugene Zelenko1-7/+6
other minor fixes (NFC). llvm-svn: 301275
2016-11-01[RISCV] Add RISC-V ELF definesAlex Bradbury1-0/+7
Add the necessary definitions for RISC-V ELF files, including relocs. Also make necessary trivial change to ELFYaml, llvm-objdump, and llvm-readobj in order to work with RISC-V ELFs. Differential Revision: https://reviews.llvm.org/D23557 llvm-svn: 285708
2016-09-28[AVR] Handle AVR relocations when handling ELF filesDylan McKay1-0/+7
llvm-svn: 282586
2016-07-15BPF: Use official ELF e_machine valueAlexei Starovoitov1-0/+6
The same value for EM_BPF is being propagated to glibc, elfutils, and binutils. Signed-off-by: Richard Henderson <rth@twiddle.net> Signed-off-by: Alexei Starovoitov <ast@kernel.org> llvm-svn: 275633
2016-06-17Support/ELF: Add AMDGPU relocation definitions to match documentationTom Stellard1-0/+7
Reviewers: arsenm, kzhuravl, rafael Subscribers: llvm-commits, kzhuravl Differential Revision: http://reviews.llvm.org/D21443 llvm-svn: 273066
2016-03-01[lanai] Add ELF enum value and relocations.Jacques Pienaar1-0/+7
Add ELF enum value and relocations for Lanai backed. General Lanai backend discussion on llvm-dev thread "[RFC] Lanai backend" (http://lists.llvm.org/pipermail/llvm-dev/2016-February/095118.html). Differential Revision: http://reviews.llvm.org/D17008 llvm-svn: 262394
generated by cgit v1.1 at 2025-10-02 00:19:55 +0000