|
Revision tags: llvmorg-20.1.0, llvmorg-20.1.0-rc3, llvmorg-20.1.0-rc2, llvmorg-20.1.0-rc1, llvmorg-21-init, llvmorg-19.1.7, llvmorg-19.1.6, llvmorg-19.1.5, llvmorg-19.1.4, llvmorg-19.1.3, llvmorg-19.1.2, llvmorg-19.1.1, llvmorg-19.1.0, llvmorg-19.1.0-rc4, llvmorg-19.1.0-rc3, llvmorg-19.1.0-rc2, llvmorg-19.1.0-rc1, llvmorg-20-init, llvmorg-18.1.8, llvmorg-18.1.7, llvmorg-18.1.6, llvmorg-18.1.5, llvmorg-18.1.4, llvmorg-18.1.3, llvmorg-18.1.2, llvmorg-18.1.1, llvmorg-18.1.0, llvmorg-18.1.0-rc4, llvmorg-18.1.0-rc3, llvmorg-18.1.0-rc2, llvmorg-18.1.0-rc1, llvmorg-19-init, llvmorg-17.0.6, llvmorg-17.0.5, llvmorg-17.0.4, llvmorg-17.0.3, llvmorg-17.0.2, llvmorg-17.0.1, llvmorg-17.0.0, llvmorg-17.0.0-rc4, llvmorg-17.0.0-rc3, llvmorg-17.0.0-rc2, llvmorg-17.0.0-rc1, llvmorg-18-init, llvmorg-16.0.6, llvmorg-16.0.5, llvmorg-16.0.4, llvmorg-16.0.3, llvmorg-16.0.2, llvmorg-16.0.1, llvmorg-16.0.0, llvmorg-16.0.0-rc4, llvmorg-16.0.0-rc3, llvmorg-16.0.0-rc2, llvmorg-16.0.0-rc1, llvmorg-17-init, llvmorg-15.0.7, llvmorg-15.0.6, llvmorg-15.0.5, llvmorg-15.0.4, llvmorg-15.0.3, llvmorg-15.0.2, llvmorg-15.0.1, llvmorg-15.0.0, llvmorg-15.0.0-rc3 |
|
| #
e2da7244 |
| 12-Aug-2022 |
Fangrui Song <[email protected]> |
[MCDwarf] Respect -fdebug-prefix-map= for generated assembly debug info (DWARF v5)
For generated assembly debug info, MCDwarfLineTableHeader::CompilationDir is an unmapped path set in MCContext::set
[MCDwarf] Respect -fdebug-prefix-map= for generated assembly debug info (DWARF v5)
For generated assembly debug info, MCDwarfLineTableHeader::CompilationDir is an unmapped path set in MCContext::setGenDwarfRootFile. Remap it.
A relative destination path of -fdebug-prefix-map= exposes a llvm-dwarfdump bug which joins relative DW_AT_comp_dir and directories[0].
Fix https://github.com/llvm/llvm-project/issues/56609
Reviewed By: dblaikie
Differential Revision: https://reviews.llvm.org/D131749
(cherry picked from commit f62e60fb238146113f84e0efb1a2ebc52f05cc0a)
show more ...
|
| #
c4398881 |
| 12-Aug-2022 |
Fangrui Song <[email protected]> |
[MCDwarf] Use emplace to avoid move assignment. NFC
(cherry picked from commit b0c4cd35df89479ec152c1f79e18d0264dd276cc)
|
|
Revision tags: llvmorg-15.0.0-rc2, llvmorg-15.0.0-rc1, llvmorg-16-init, llvmorg-14.0.6 |
|
| #
0916d96d |
| 21-Jun-2022 |
Kazu Hirata <[email protected]> |
Don't use Optional::hasValue (NFC)
|
| #
129b531c |
| 19-Jun-2022 |
Kazu Hirata <[email protected]> |
[llvm] Use value_or instead of getValueOr (NFC)
|
| #
d4bcb45d |
| 12-Jun-2022 |
Jez Ng <[email protected]> |
[MC][re-land] Omit DWARF unwind info if compact unwind is present where eligible
This reverts commit d941d597837d9e1405086f008c9bd6a71e7263c9.
Differential Revision: https://reviews.llvm.org/D122258
|
| #
d941d597 |
| 12-Jun-2022 |
Jez Ng <[email protected]> |
Revert "[MC] Omit DWARF unwind info if compact unwind is present where eligible"
This reverts commit ef501bf85d8c869248e51371f0e74bcec0e7b229.
|
| #
ef501bf8 |
| 12-Jun-2022 |
Jez Ng <[email protected]> |
[MC] Omit DWARF unwind info if compact unwind is present where eligible
Previously, omitting unnecessary DWARF unwinds was only done in two cases: * For Darwin + aarch64, if no DWARF unwind info is
[MC] Omit DWARF unwind info if compact unwind is present where eligible
Previously, omitting unnecessary DWARF unwinds was only done in two cases: * For Darwin + aarch64, if no DWARF unwind info is needed for all the functions in a TU, then the `__eh_frame` section would be omitted entirely. If any one function needed DWARF unwind, then MC would emit DWARF unwind entries for all the functions in the TU. * For watchOS, MC would omit DWARF unwind on a per-function basis, as long as compact unwind was available for that function.
This diff makes it so that we omit DWARF unwind on a per-function basis for Darwin + aarch64 as well. In addition, we introduce the flag `--emit-dwarf-unwind=` which can toggle between `always`, `no-compact-unwind` (only emit DWARF when CU cannot be emitted for a given function), and the target platform `default`. `no-compact-unwind` is particularly useful for newer x86_64 platforms: we don't want to omit DWARF unwind for x86_64 in general due to possible backwards compat issues, but we should make it possible for people to opt into this behavior if they are only targeting newer platforms.
**Motivation:** I'm working on adding support for `__eh_frame` to LLD, but I'm concerned that we would suffer a perf hit. Processing compact unwind is already expensive, and that's a simpler format than EH frames. Given that MC currently produces one EH frame entry for every compact unwind entry, I don't think processing them will be cheap. I tried to do something clever on LLD's end to drop the unnecessary EH frames at parse time, but this made the code significantly more complex. So I'm looking at fixing this at the MC level instead.
**Addendum:** It turns out that there was a latent bug in the X86 backend when `OmitDwarfIfHaveCompactUnwind` is naively enabled, which is not too surprising given that this combination has not been heretofore used.
For functions that have unwind info that cannot be encoded with CU, MC would end up dropping both the compact unwind entry (OK; existing behavior) as well as the DWARF entries (not OK). This diff fixes things so that we emit the DWARF entry, as well as a CU entry with encoding `UNWIND_X86_MODE_DWARF` -- this basically tells the unwinder to look for the DWARF entry. I'm not 100% sure the `UNWIND_X86_MODE_DWARF` CU entry is necessary, this was the simplest fix. ld64 seems to be able to handle both the absence and presence of this CU entry. Ultimately ld64 (and LLD) will synthesize `UNWIND_X86_MODE_DWARF` if it is absent, so there is no impact to the final binary size.
Reviewed By: davide, lhames
Differential Revision: https://reviews.llvm.org/D122258
show more ...
|
| #
adf4142f |
| 11-Jun-2022 |
Fangrui Song <[email protected]> |
[MC] De-capitalize SwitchSection. NFC
Add SwitchSection to return switchSection. The API will be removed soon.
|
|
Revision tags: llvmorg-14.0.5 |
|
| #
0593ce5f |
| 03-Jun-2022 |
Florian Mayer <[email protected]> |
[MC] Add 'G' to augmentation string for MTE instrumented functions
This was agreed on in https://lists.llvm.org/pipermail/llvm-dev/2020-May/141345.html
The thread proposed two options * add a chara
[MC] Add 'G' to augmentation string for MTE instrumented functions
This was agreed on in https://lists.llvm.org/pipermail/llvm-dev/2020-May/141345.html
The thread proposed two options * add a character to augmentation string and handle in libuwind * use a separate personality function.
It was determined that this is the simpler and better option.
This is part of ARM's Aarch64 ABI: https://github.com/ARM-software/abi-aa/blob/main/aadwarf64/aadwarf64.rst#id22
The next step after this is teaching libunwind to untag when this augmentation character is set.
Reviewed By: MaskRay, eugenis
Differential Revision: https://reviews.llvm.org/D127007
show more ...
|
|
Revision tags: llvmorg-14.0.4, llvmorg-14.0.3, llvmorg-14.0.2 |
|
| #
c87d405b |
| 21-Apr-2022 |
Alexander Yermolovich <[email protected]> |
[DWARF] Add API to get data from MCDwarfLineStr
This API will be used in D121876, to get finalized string data for .debug_line_str.
Reviewed By: dblaikie, rafauler
Differential Revision: https://r
[DWARF] Add API to get data from MCDwarfLineStr
This API will be used in D121876, to get finalized string data for .debug_line_str.
Reviewed By: dblaikie, rafauler
Differential Revision: https://reviews.llvm.org/D124052
show more ...
|
|
Revision tags: llvmorg-14.0.1 |
|
| #
330268ba |
| 04-Apr-2022 |
Argyrios Kyrtzidis <[email protected]> |
[Support/Hash functions] Change the `final()` and `result()` of the hashing functions to return an array of bytes
Returning `std::array<uint8_t, N>` is better ergonomics for the hashing functions us
[Support/Hash functions] Change the `final()` and `result()` of the hashing functions to return an array of bytes
Returning `std::array<uint8_t, N>` is better ergonomics for the hashing functions usage, instead of a `StringRef`:
* When returning `StringRef`, client code is "jumping through hoops" to do string manipulations instead of dealing with fixed array of bytes directly, which is more natural * Returning `std::array<uint8_t, N>` avoids the need for the hasher classes to keep a field just for the purpose of wrapping it and returning it as a `StringRef`
As part of this patch also:
* Introduce `TruncatedBLAKE3` which is useful for using BLAKE3 as the hasher type for `HashBuilder` with non-default hash sizes. * Make `MD5Result` inherit from `std::array<uint8_t, 16>` which improves & simplifies its API.
Differential Revision: https://reviews.llvm.org/D123100
show more ...
|
|
Revision tags: llvmorg-14.0.0, llvmorg-14.0.0-rc4, llvmorg-14.0.0-rc3, llvmorg-14.0.0-rc2, llvmorg-14.0.0-rc1, llvmorg-15-init |
|
| #
f15014ff |
| 26-Jan-2022 |
Benjamin Kramer <[email protected]> |
Revert "Rename llvm::array_lengthof into llvm::size to match std::size from C++17"
This reverts commit ef8206320769ad31422a803a0d6de6077fd231d2.
- It conflicts with the existing llvm::size in STLEx
Revert "Rename llvm::array_lengthof into llvm::size to match std::size from C++17"
This reverts commit ef8206320769ad31422a803a0d6de6077fd231d2.
- It conflicts with the existing llvm::size in STLExtras, which will now never be called. - Calling it without llvm:: breaks C++17 compat
show more ...
|
| #
ef820632 |
| 26-Jan-2022 |
serge-sans-paille <[email protected]> |
Rename llvm::array_lengthof into llvm::size to match std::size from C++17
As a conquence move llvm::array_lengthof from STLExtras.h to STLForwardCompat.h (which is included by STLExtras.h so no buil
Rename llvm::array_lengthof into llvm::size to match std::size from C++17
As a conquence move llvm::array_lengthof from STLExtras.h to STLForwardCompat.h (which is included by STLExtras.h so no build breakage expected).
show more ...
|
| #
86b08ed6 |
| 21-Jan-2022 |
Igor Kudrin <[email protected]> |
[DebugInfo][NFC] Do not call 'isRootFile' for DWARF Version < 5
A quicker comparison should be done first.
Differential Revision: https://reviews.llvm.org/D117786
|
| #
75184f14 |
| 21-Jan-2022 |
Igor Kudrin <[email protected]> |
[DebugInfo] Fix handling '# line "file"' for DWARFv5
`CppHashInfo.Filename` is a `StringRef` that references a part of the source file and it is not null-terminated at the end of the file name. `Asm
[DebugInfo] Fix handling '# line "file"' for DWARFv5
`CppHashInfo.Filename` is a `StringRef` that references a part of the source file and it is not null-terminated at the end of the file name. `AsmParser::parseAndMatchAndEmitTargetInstruction()` passes it to `getStreamer().emitDwarfFileDirective()`, and it eventually comes to `isRootFile()`. The comparison fails because `FileName.data()` is not properly terminated.
In addition, the old code might cause a significant speed degradation for long source files. The `operator!=()` for `std::string` and `const char *` can be implemented in a way that it finds the length of the second argument first, which slows the comparison for long data. `parseAndMatchAndEmitTargetInstruction()` calls `emitDwarfFileDirective()` every time if `CppHashInfo.Filename` is not empty. As a result, the longer the source file is, the slower the compilation wend, and for a very long file, it might take hours instead of a couple of seconds normally.
Differential Revision: https://reviews.llvm.org/D117785
show more ...
|
|
Revision tags: llvmorg-13.0.1, llvmorg-13.0.1-rc3, llvmorg-13.0.1-rc2, llvmorg-13.0.1-rc1 |
|
| #
6747d44b |
| 15-Nov-2021 |
Kyungwoo Lee <[email protected]> |
[DebugInfo] Fix end_sequence of debug_line in LTO Object
In a LTO build, the `end_sequence` in debug_line table for each compile unit (CU) points the end of text section which merged all CUs. The `e
[DebugInfo] Fix end_sequence of debug_line in LTO Object
In a LTO build, the `end_sequence` in debug_line table for each compile unit (CU) points the end of text section which merged all CUs. The `end_sequence` needs to point to the end of each CU's range. This bug often causes invalid `debug_line` table in the final `.dSYM` binary for MachO after running `dsymutil` which tries to compensate an out-of-range address of `end_sequence`. The fix is to sync the line table termination with the range operations that are already maintained in DwarfDebug. When CU or section changes, or nodebug functions appear or module is finished, the prior pending line table is terminated using the last range label. In the MC path where no range is tracked, the old logic is conservatively used to end the line table using the section end symbol.
Reviewed By: dblaikie
Differential Revision: https://reviews.llvm.org/D108261
show more ...
|
|
Revision tags: llvmorg-13.0.0, llvmorg-13.0.0-rc4 |
|
| #
050edef8 |
| 17-Sep-2021 |
Maksim Panchenko <[email protected]> |
[MC] Make MCDwarfLineStr class public
Add MCDwarfLineStr class to the public API.
Note that MCDwarfLineTableHeader::Emit(), takes MCDwarfLineStr as an Optional<> parameter making it impossible to u
[MC] Make MCDwarfLineStr class public
Add MCDwarfLineStr class to the public API.
Note that MCDwarfLineTableHeader::Emit(), takes MCDwarfLineStr as an Optional<> parameter making it impossible to use the API if the class is not publicly defined.
Reviewed By: alexander-shaposhnikov
Differential Revision: https://reviews.llvm.org/D109412
show more ...
|
|
Revision tags: llvmorg-13.0.0-rc3, llvmorg-13.0.0-rc2, llvmorg-13.0.0-rc1, llvmorg-14-init, llvmorg-12.0.1, llvmorg-12.0.1-rc4, llvmorg-12.0.1-rc3, llvmorg-12.0.1-rc2 |
|
| #
bbea6425 |
| 26-May-2021 |
Saleem Abdulrasool <[email protected]> |
RISCV: adjust handling of relocation emission for RISCV
This re-architects the RISCV relocation handling to bring the implementation closer in line with the implementation in binutils. We would pre
RISCV: adjust handling of relocation emission for RISCV
This re-architects the RISCV relocation handling to bring the implementation closer in line with the implementation in binutils. We would previously aggressively resolve the relocation. With this restructuring, we always will emit a paired relocation for any symbolic difference of the type of S±T[±C] where S and T are labels and C is a constant.
GAS has a special target hook controlled by `RELOC_EXPANSION_POSSIBLE` which indicates that a fixup may be expanded into multiple relocations. This is used by the RISCV backend to always emit a paired relocation - either ADD[WIDTH] + SUB[WIDTH] for text relocations or SET[WIDTH] + SUB[WIDTH] for a debug info relocation. Irrespective of whether linker relaxation support is enabled, symbolic difference is always emitted as a paired relocation.
This change also sinks the target specific behaviour down into the target specific area rather than exposing it to the shared relocation handling. In the process, we also sink the "special" handling for debug information down into the RISCV target. Although this improves the path for the other targets, this is not necessarily entirely ideal either. The changes in the debug info emission could be done through another type of hook as this functionality would be required by any other target which wishes to do linker relaxation. However, as there are no other targets in LLVM which currently do this, this is a reasonable thing to do until such time as the code needs to be shared.
Improve the handling of the relocation (and add a reduced test case from the Linux kernel) to ensure that we handle complex expressions for symbolic difference. This ensures that we correct relocate symbols with the adddends normalized and associated with the addition portion of the paired relocation.
This change also addresses some review comments from Alex Bradbury about the relocations meant for use in the DWARF CFA being named incorrectly (using ADD6 instead of SET6) in the original change which introduced the relocation type.
This resolves the issues with the symbolic difference emission sufficiently to enable building the Linux kernel with clang+IAS+lld (without linker relaxation).
Resolves PR50153, PR50156! Fixes: ClangBuiltLinux/linux#1023, ClangBuiltLinux/linux#1143
Reviewed By: nickdesaulniers, maskray
Differential Revision: https://reviews.llvm.org/D103539
show more ...
|
| #
167e7afc |
| 14-Jun-2021 |
RamNalamothu <[email protected]> |
Implement DW_CFA_LLVM_* for Heterogeneous Debugging
Add support in MC/MIR for writing/parsing, and DebugInfo.
This is part of the Extensions for Heterogeneous Debugging defined at https://llvm.org/
Implement DW_CFA_LLVM_* for Heterogeneous Debugging
Add support in MC/MIR for writing/parsing, and DebugInfo.
This is part of the Extensions for Heterogeneous Debugging defined at https://llvm.org/docs/AMDGPUDwarfExtensionsForHeterogeneousDebugging.html
Specifically the CFI instructions implemented here are defined at https://llvm.org/docs/AMDGPUDwarfExtensionsForHeterogeneousDebugging.html#cfa-definition-instructions
Reviewed By: clayborg
Differential Revision: https://reviews.llvm.org/D76877
show more ...
|
|
Revision tags: llvmorg-12.0.1-rc1, llvmorg-12.0.0, llvmorg-12.0.0-rc5, llvmorg-12.0.0-rc4 |
|
| #
fafbdfe6 |
| 12-Mar-2021 |
Esme-Yi <[email protected]> |
[Debug-Info] Add names for the debug line prologue.
Summary: This is a minor patch to add names for the debug line prologue, as a follow-up of D95998.
Reviewed By: dblaikie, ikudrin, shchenz
Diffe
[Debug-Info] Add names for the debug line prologue.
Summary: This is a minor patch to add names for the debug line prologue, as a follow-up of D95998.
Reviewed By: dblaikie, ikudrin, shchenz
Differential Revision: https://reviews.llvm.org/D98383
show more ...
|
|
Revision tags: llvmorg-12.0.0-rc3 |
|
| #
87bbf3d1 |
| 05-Mar-2021 |
Chen Zheng <[email protected]> |
[XCOFF][DebugInfo] support DWARF for XCOFF for assembly output.
Reviewed By: jasonliu
Differential Revision: https://reviews.llvm.org/D95518
|
| #
ed8f29d9 |
| 28-Feb-2021 |
Chen Zheng <[email protected]> |
[Debug-Info][NFC] use emitDwarfUnitLength for debug line section
Use emitDwarfUnitLength for debug line, so we can benefit from overriding of emitDwarfUnitLength inside different streamers.
Reviewe
[Debug-Info][NFC] use emitDwarfUnitLength for debug line section
Use emitDwarfUnitLength for debug line, so we can benefit from overriding of emitDwarfUnitLength inside different streamers.
Reviewed By: ikudrin, dblaikie
Differential Revision: https://reviews.llvm.org/D95998
show more ...
|
|
Revision tags: llvmorg-12.0.0-rc2, llvmorg-11.1.0, llvmorg-11.1.0-rc3, llvmorg-12.0.0-rc1, llvmorg-13-init, llvmorg-11.1.0-rc2 |
|
| #
2b4716d6 |
| 21-Jan-2021 |
Mikael Holmen <[email protected]> |
[MC] Use std::make_tuple to make some toolchains happy again
My toolchain (LLVM 8.0, libstdc++ 5.4.0) complained with:
12:27:43 ../lib/MC/MCDwarf.cpp:814:10: error: chosen constructor is explicit i
[MC] Use std::make_tuple to make some toolchains happy again
My toolchain (LLVM 8.0, libstdc++ 5.4.0) complained with:
12:27:43 ../lib/MC/MCDwarf.cpp:814:10: error: chosen constructor is explicit in copy-initialization 12:27:43 return {Offset, Size, SetDelta}; 12:27:43 ^~~~~~~~~~~~~~~~~~~~~~~~ 12:27:43 /proj/flexasic/app/llvm/8.0/bin/../lib/gcc/x86_64-unknown-linux-gnu/5.4.0/../../../../include/c++/5.4.0/tuple:479:19: note: explicit constructor declared here 12:27:43 constexpr tuple(_UElements&&... __elements) 12:27:43 ^ 12:27:43 1 error generated.
This commit adds explicit calls to std::make_tuple to work around the problem.
show more ...
|
| #
71635ea5 |
| 21-Jan-2021 |
Fangrui Song <[email protected]> |
MCDwarf: Delete uneeded parameter
And change signature
|
|
Revision tags: llvmorg-11.1.0-rc1 |
|
| #
d9a0c40b |
| 21-Dec-2020 |
Fangrui Song <[email protected]> |
[MC] Split MCContext::createTempSymbol, default AlwaysAddSuffix to true, and add comments
CanBeUnnamed is rarely false. Splitting to a createNamedTempSymbol makes the intention clearer and matches t
[MC] Split MCContext::createTempSymbol, default AlwaysAddSuffix to true, and add comments
CanBeUnnamed is rarely false. Splitting to a createNamedTempSymbol makes the intention clearer and matches the direction of reverted r240130 (to drop the unneeded parameters).
No behavior change.
show more ...
|