aboutsummaryrefslogtreecommitdiff
path: root/llvm/lib/Object/ELFObjectFile.cpp
AgeCommit message (Collapse)AuthorFilesLines
2022-12-04[Object] llvm::Optional => std::optionalFangrui Song1-7/+7
2022-12-02[llvm] Use std::nullopt instead of None (NFC)Kazu Hirata1-2/+2
This patch mechanically replaces None with std::nullopt where the compiler would warn if None were deprecated. The intent is to reduce the amount of manual work required in migrating from Optional to std::optional. This is part of an effort to migrate from llvm::Optional to std::optional: https://discourse.llvm.org/t/deprecating-llvm-optional-x-hasvalue-getvalue-getvalueor/63716
2022-12-02AttributeParser: Convert Optional to std::optionalFangrui Song1-4/+5
2022-12-01[Object] Add some more LoongArch supportWANG Xuerui1-0/+20
Add ELFObjectFileBase::getLoongArchFeatures, and return the proper ELF relative reloc type for LoongArch. Reviewed By: MaskRay, SixWeining Differential Revision: https://reviews.llvm.org/D138016
2022-11-25[Object] Use std::optional in ELFObjectFile.cpp (NFC)Kazu Hirata1-1/+2
This is part of an effort to migrate from llvm::Optional to std::optional: https://discourse.llvm.org/t/deprecating-llvm-optional-x-hasvalue-getvalue-getvalueor/63716
2022-11-23[Object] Internalize readBBAddrMapImplFangrui Song1-3/+2
2022-08-20Remove redundant initialization of Optional (NFC)Kazu Hirata1-1/+1
2022-08-08[llvm] LLVM_FALLTHROUGH => [[fallthrough]]. NFCFangrui Song1-1/+1
With C++17 there is no Clang pedantic warning or MSVC C5051.
2022-07-13[llvm] Use value instead of getValue (NFC)Kazu Hirata1-9/+9
2022-06-30[llvm-objdump] Default to --mcpu=future for PPC64Fangrui Song1-0/+2
GNU objdump disassembles all unknown instructions by default. Match this user friendly behavior with the cpu value `future`. Differential Revision: https://reviews.llvm.org/D127824
2022-06-28[Propeller] Encode address offsets of basic blocks relative to the end of ↵Rahman Lavaee1-1/+2
the previous basic blocks. This is a resurrection of D106421 with the change that it keeps backward-compatibility. This means decoding the previous version of `LLVM_BB_ADDR_MAP` will work. This is required as the profile mapping tool is not released with LLVM (AutoFDO). As suggested by @jhenderson we rename the original section type value to `SHT_LLVM_BB_ADDR_MAP_V0` and assign a new value to the `SHT_LLVM_BB_ADDR_MAP` section type. The new encoding adds a version byte to each function entry to specify the encoding version for that function. This patch also adds a feature byte to be used with more flexibility in the future. An use-case example for the feature field is encoding multi-section functions more concisely using a different format. Conceptually, the new encoding emits basic block offsets and sizes as label differences between each two consecutive basic block begin and end label. When decoding, offsets must be aggregated along with basic block sizes to calculate the final offsets of basic blocks relative to the function address. This encoding uses smaller values compared to the existing one (offsets relative to function symbol). Smaller values tend to occupy fewer bytes in ULEB128 encoding. As a result, we get about 17% total reduction in the size of the bb-address-map section (from about 11MB to 9MB for the clang PGO binary). The extra two bytes (version and feature fields) incur a small 3% size overhead to the `LLVM_BB_ADDR_MAP` section size. Reviewed By: jhenderson Differential Revision: https://reviews.llvm.org/D121346
2022-06-25[llvm] Don't use Optional::hasValue (NFC)Kazu Hirata1-9/+9
This patch replaces Optional::hasValue with the implicit cast to bool in conditionals only.
2022-06-25Revert "Don't use Optional::hasValue (NFC)"Kazu Hirata1-18/+18
This reverts commit aa8feeefd3ac6c78ee8f67bf033976fc7d68bc6d.
2022-06-25Don't use Optional::hasValue (NFC)Kazu Hirata1-18/+18
2022-06-20[llvm] Don't use Optional::getValue (NFC)Kazu Hirata1-1/+1
2022-06-20[llvm] Don't use Optional::hasValue (NFC)Kazu Hirata1-1/+1
2022-05-16[llvm-objdump] Let --symbolize-operands symbolize basic block addresses ↵Rahman Lavaee1-0/+43
based on the SHT_LLVM_BB_ADDR_MAP section. `--symbolize-operands` already symbolizes branch targets based on the disassembly. When the object file is created with `-fbasic-block-sections=labels` (ELF-only) it will include a SHT_LLVM_BB_ADDR_MAP section which maps basic blocks to their addresses. In such case `llvm-objdump` can annotate the disassembly based on labels inferred on this section. In contrast to the current labels, SHT_LLVM_BB_ADDR_MAP-based labels are created for every machine basic block including empty blocks and those which are not branched into (fallthrough blocks). The old logic is still executed even when the SHT_LLVM_BB_ADDR_MAP section is present to handle functions which have not been received an entry in this section. Reviewed By: jhenderson, MaskRay Differential Revision: https://reviews.llvm.org/D124560
2022-04-29[AMDGPU] Add gfx11 subtarget ELF definitionJoe Nash1-0/+10
This is the first patch of a series to upstream support for the new subtarget. Contributors: Jay Foad <jay.foad@amd.com> Konstantin Zhuravlyov <kzhuravl_dev@outlook.com> Patch 1/N for upstreaming AMDGPU gfx11 architectures. Reviewed By: foad, kzhuravl, #amdgpu Differential Revision: https://reviews.llvm.org/D124536
2022-04-28[ARM] add Armv9 build attributeTies Stuij1-0/+3
The build attribute number can be found in the Arm ABI addenda32 document: https://github.com/ARM-software/abi-aa/blob/main/addenda32/addenda32.rst#335target-related-attributes Reviewed By: tmatheson Differential Revision: https://reviews.llvm.org/D124090
2022-03-02[AMDGPU] Add gfx1036 targetAakanksha1-0/+2
Differential Revision: https://reviews.llvm.org/D120846
2022-03-02[AMDGPU] Add gfx940 targetStanislav Mekhanoshin1-0/+2
This is target definition only. Differential Revision: https://reviews.llvm.org/D120688
2022-02-10Cleanup LLVMObject headersserge-sans-paille1-2/+0
Most notably, llvm/Object/Binary.h no longer includes llvm/Support/MemoryBuffer.h llvm/Object/MachOUniversal*.h no longer include llvm/Object/Archive.h llvm/Object/TapiUniversal.h no longer includes llvm/Object/TapiFile.h llvm-project preprocessed size: before: 1068185081 after: 1068324320 Discourse thread: https://discourse.llvm.org/t/include-what-you-use-include-cleanup Differential Revision: https://reviews.llvm.org/D119457
2021-11-29[llvm] Use range-based for loops (NFC)Kazu Hirata1-2/+2
2021-10-08Move TargetRegistry.(h|cpp) from Support to MCReid Kleckner1-1/+1
This moves the registry higher in the LLVM library dependency stack. Every client of the target registry needs to link against MC anyway to actually use the target, so we might as well move this out of Support. This allows us to ensure that Support doesn't have includes from MC/*. Differential Revision: https://reviews.llvm.org/D111454
2021-08-17[Object] Move llvm-nm's symbol version utility to ↵Fangrui Song1-0/+69
ELFObjectFile::readDynsymVersions The utility can be reused by llvm-objdump -T. Reviewed By: jhenderson Differential Revision: https://reviews.llvm.org/D108096
2021-07-28[ARM] Fix llvm-objdump disassembly of armv7m object files.Eli Friedman1-2/+9
Apparently, the features were getting mixed up, so we'd try to disassemble in ARM mode. Fix sub-architecture detection to compute the correct triple if we're detecting it automatically, so the user doesn't need to pass --triple=thumb etc. It's possible we should be somehow tying the "+thumb-mode" target feature more directly to Tag_CPU_arch_profile? But this seems to work reasonably well, anyway. While I'm here, fix up the other llvm-objdump tests that were explicitly specifying an ARM triple; that shouldn't be necessary. Differential Revision: https://reviews.llvm.org/D106912
2021-06-24[AMDGPU] Add gfx1035 targetAakanksha Patil1-0/+2
Differential Revision: https://reviews.llvm.org/D104804
2021-06-08Reland "[AMDGPU] Add gfx1013 target"Brendon Cahoon1-0/+2
This reverts commit 211e584fa2a4c032e4d573e7cdbffd622aad0a8f. Fixed a use-after-free error that caused the sanitizers to fail.
2021-06-08Revert "[AMDGPU] Add gfx1013 target"Brendon Cahoon1-2/+0
This reverts commit ea10a86984ea73fcec3b12d22404a15f2f59b219. A sanitizer buildbot reports an error.
2021-06-08[AMDGPU] Add gfx1013 targetBrendon Cahoon1-0/+2
Differential Revision: https://reviews.llvm.org/D103663
2021-05-13[AMDGPU] Add gfx1034 targetAakanksha Patil1-0/+2
Differential Revision: https://reviews.llvm.org/D102306
2021-02-17[AMDGPU] gfx90a supportStanislav Mekhanoshin1-0/+2
Differential Revision: https://reviews.llvm.org/D96906
2021-02-08[llvm-objdump] Support PLT decoding for aarch64_beFangrui Song1-0/+1
Reviewed By: jhenderson Differential Revision: https://reviews.llvm.org/D96211
2020-12-22Replace `T(x)` with `reinterpret_cast<T>(x)` everywhere it means ↵Arthur O'Dwyer1-1/+2
reinterpret_cast. NFC. Differential Revision: https://reviews.llvm.org/D76572
2020-11-09Recommit: [llvm-readelf/obj] - Allow dumping of ELF header even if some ↵Georgii Rymar1-7/+7
elements are corrupt. This is recommit for D90903 with fixes for BB: 1) Used std::move<> when returning Expected<> (http://lab.llvm.org:8011/#/builders/112/builds/913) 2) Fixed the name of temporarily file in the file-headers.test (http://lab.llvm.org:8011/#/builders/36/builds/1269) (a local old temporarily file was used before) For creating `ELFObjectFile` instances we have the factory method `ELFObjectFile<ELFT>::create(MemoryBufferRef Object)`. The problem of this method is that it scans the section header to locate some sections. When a file is truncated or has broken fields in the ELF header, this approach does not allow us to create the `ELFObjectFile` and dump the ELF header. This is https://bugs.llvm.org/show_bug.cgi?id=40804 This patch suggests a solution - it allows to delay scaning sections in the `ELFObjectFile<ELFT>::create`. It now allows user code to call an object initialization (`initContent()`) later. With that it is possible, for example, for dumpers just to dump the file header and exit. By default initialization is still performed as before, what helps to keep the logic of existent callers untouched. I've experimented with different approaches when worked on this patch. I think this approach is better than doing initialization of sections (i.e. scan of them) on demand, because normally users of `ELFObjectFile` API expect to work with a valid object. In most cases when a section header table can't be read (because of an error), we don't have to continue to work with object. So we probably don't need to implement a more complex API. Differential revision: https://reviews.llvm.org/D90903
2020-11-09Revert "[llvm-readelf/obj] - Allow dumping of ELF header even if some ↵Georgii Rymar1-7/+7
elements are corrupt." This reverts commit ea8a0b8b29eb08d3f0f6ac40942a2d8e98ab57ee. It broke BBots. http://lab.llvm.org:8011/#/builders/14/builds/1439 http://lab.llvm.org:8011/#/builders/112/builds/913
2020-11-09[llvm-readelf/obj] - Allow dumping of ELF header even if some elements are ↵Georgii Rymar1-7/+7
corrupt. For creating `ELFObjectFile` instances we have the factory method `ELFObjectFile<ELFT>::create(MemoryBufferRef Object)`. The problem of this method is that it scans the section header to locate some sections. When a file is truncated or has broken fields in the ELF header, this approach does not allow us to create the `ELFObjectFile` and dump the ELF header. This is https://bugs.llvm.org/show_bug.cgi?id=40804 This patch suggests a solution - it allows to delay scaning sections in the `ELFObjectFile<ELFT>::create`. It now allows user code to call an object initialization (`initContent()`) later. With that it is possible, for example, for dumpers just to dump the file header and exit. By default initialization is still performed as before, what helps to keep the logic of existent callers untouched. I've experimented with different approaches when worked on this patch. I think this approach is better than doing initialization of sections (i.e. scan of them) on demand, because normally users of `ELFObjectFile` API expect to work with a valid object. In most cases when a section header table can't be read (because of an error), we don't have to continue to work with object. So we probably don't need to implement a more complex API. Differential revision: https://reviews.llvm.org/D90903
2020-11-03[AMDGPU] Add gfx1033 targetTim Renouf1-0/+2
Differential Revision: https://reviews.llvm.org/D90447 Change-Id: If2650fc7f31bbdd49c76e74a9ca8e3734d769761
2020-11-03[AMDGPU] Add gfx90c targetTim Renouf1-0/+2
This differentiates the Ryzen 4000/4300/4500/4700 series APUs that were previously included in gfx909. Differential Revision: https://reviews.llvm.org/D90419 Change-Id: Ia901a7157eb2f73ccd9f25dbacec38427312377d
2020-10-27[AMDGPU] Add missing support for targetsTony1-1/+4
- Add missing tests. Differential Revision: https://reviews.llvm.org/D90212
2020-10-10[AMDGPU] Add gfx602, gfx705, gfx805 targetsTim Renouf1-0/+6
At AMD, in an internal audit of our code, we found some corner cases where we were not quite differentiating targets enough for some old hardware. This commit is part of fixing that by adding three new targets: * The "Oland" and "Hainan" variants of gfx601 are now split out into gfx602. LLPC (in the GPUOpen driver) and other front-ends could use that to avoid using the shaderZExport workaround on gfx602. * One variant of gfx703 is now split out into gfx705. LLPC and other front-ends could use that to avoid using the shaderSpiCsRegAllocFragmentation workaround on gfx705. * The "TongaPro" variant of gfx802 is now split out into gfx805. TongaPro has a faster 64-bit shift than its former friends in gfx802, and a subtarget feature could be set up for that to take advantage of it. This commit does not make that change; it just adds the target. V2: Add clang changes. Put TargetParser list in order. V3: AMDGCNGPUs table in TargetParser.cpp needs to be in GPUKind order, so fix the GPUKind order. Differential Revision: https://reviews.llvm.org/D88916 Change-Id: Ia901a7157eb2f73ccd9f25dbacec38427312377d
2020-08-18[llvm-objdump][AMDGPU] Detect CPU stringRonak Chauhan1-0/+111
AMDGPU ISA isn't backwards compatible and hence -mcpu must always be specified during disassembly. However, the AMDGPU target CPU is stored in e_flags in the ELF object. This patch allows targets to implement CPU string detection, and also implements it for AMDGPU by looking at e_flags. Reviewed By: scott.linder Differential Revision: https://reviews.llvm.org/D84519
2020-08-13[llvm-objdump] Change symbol name/PLT decoding errors to warningsFangrui Song1-5/+9
If the referenced symbol of a J[U]MP_SLOT is invalid (e.g. symbol index 0), llvm-objdump -d will bail out: ``` error: 'a': st_name (0x326600) is past the end of the string table of size 0x7 ``` where 0x326600 is the st_name field of the first entry past the end of .symtab Change it to a warning to continue dumping. `X86/plt.test` uses a prebuilt executable, so I pick `ELF/AArch64/plt.test` which has a YAML input and can be easily modified. Reviewed By: jhenderson Differential Revision: https://reviews.llvm.org/D85623
2020-04-10[RISCV] Consume error from parsing attributes sectionJessica Clarke1-1/+4
Summary: We don't consume the error from getBuildAttributes, so an assertions build crashes with "Program aborted due to an unhandled Error:". Explicitly consume it like the ARM version in that case. Reviewers: asb, jhenderson, MaskRay, HsiangKai Reviewed By: MaskRay Subscribers: kristof.beyls, hiraditya, simoncook, kito-cheng, shiva0217, rogfer01, rkruppe, psnobl, benna, Jim, lenary, s.egerton, sameer.abuasal, luismarques, evandro, danielkiss, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D77841
2020-03-31[RISCV] ELF attribute section for RISC-V.Kai Wang1-18/+71
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-05[ARM] Rewrite ARMAttributeParserFangrui Song1-2/+7
* Delete boilerplate * Change functions to return `Error` * Test parsing errors * Update callers of ARMAttributeParser::parse() to check the `Error` return value. Since this patch touches nearly everything in the file, I apply http://llvm.org/docs/Proposals/VariableNames.html and change variable names to lower case. Reviewed By: compnerd Differential Revision: https://reviews.llvm.org/D75015
2020-02-10Revert "Remove redundant "std::move"s in return statements"Bill Wendling1-1/+1
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-1/+1
2019-09-17[ARM] VFPv2 only supports 16 D registers.Eli Friedman1-1/+1
r361845 changed the way we handle "D16" vs. "D32" targets; there used to be a negative "d16" which removed instructions from the instruction set, and now there's a "d32" feature which adds instructions to the instruction set. This is good, but there was an oversight in the implementation: the behavior of VFPv2 was changed. In particular, the "vfp2" feature was changed to imply "d32". This is wrong: VFPv2 only supports 16 D registers. In practice, this means if you specify -mfpu=vfpv2, the compiler will generate illegal instructions. This patch gets rid of "vfp2d16" and "vfp2d16sp", and fixes "vfp2" and "vfp2sp" so they don't imply "d32". Differential Revision: https://reviews.llvm.org/D67375 llvm-svn: 372186
2019-08-28[llvm-objdump] Add the missing ARMv8 subarch detectionYi Kong1-0/+15
Differential Revision: https://reviews.llvm.org/D66849 llvm-svn: 370163
generated by cgit v1.1 at 2025-10-02 05:01:44 +0000