| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
This reverts commit aabf18d7184298566993e3141606cd79ff617d2d.
#157529 included a test that used clang, which doesn't exists in some
CI. #158343 reverts it.
This PR reapplies the original patch with the incorrect test removed.
### Context
#99710 introduced `.loc_label` so we can terminate a line sequence.
However, it did not advance PC properly. This is problematic for
1-instruction functions as it will have zero-length sequence. The test
checked in that PR shows the problem:
```
# CHECK-LINE-TABLE: Address Line Column File ISA Discriminator OpIndex Flags
# CHECK-LINE-TABLE-NEXT: ------------------ ------ ------ ------ --- ------------- ------- -------------
# CHECK-LINE-TABLE-NEXT: 0x00000028: 05 DW_LNS_set_column (1)
# CHECK-LINE-TABLE-NEXT: 0x0000002a: 00 DW_LNE_set_address (0x0000000000000000)
# CHECK-LINE-TABLE-NEXT: 0x00000035: 01 DW_LNS_copy
# CHECK-LINE-TABLE-NEXT: 0x0000000000000000 1 1 1 0 0 0 is_stmt
# CHECK-LINE-TABLE-NEXT: 0x00000036: 00 DW_LNE_end_sequence
# CHECK-LINE-TABLE-NEXT: 0x0000000000000000 1 1 1 0 0 0 is_stmt end_sequence
```
Both rows having PC 0x0 is incorrect, and parsers won't be able to parse
them. See more explanation why this is wrong in #154851.
### Design
This PR attempts to fix this by advancing the PC to the next available
Label, and advance to the end of the section if no Label is available.
### Implementation
- `emitDwarfLineEndEntry` will advance PC to the `CurrLabel`
- If `CurrLabel` is null, its probably a fake LineEntry we introduced in
#110192. In that case look for the next Label
- If still not label can be found, use `null` and
`emitDwarfLineEndEntry` is smart enough to advance PC to the end of the
section
- Rename `LastLabel` to `PrevLabel`, "last" can mean "previous" or
"final", this is ambigous.
- Updated the tests to emit a correct label.
### Note
This fix should render #154986 and #154851 obsolete, they were temporary
fixes and don't resolve the root cause.
|
|
Reverts llvm/llvm-project#157529
Sorry, I missed that the missed that the LLVM test was using clang -
layering dictates thats not OK. Please readjust the test case to work
like the existing test coverage (or perhaps the existing test coverage
is sufficient?) and post a new PR.
|
|
### Context
#99710 introduced `.loc_label` so we can terminate a line sequence.
However, it did not advance PC properly. This is problematic for
1-instruction functions as it will have zero-length sequence. The test
checked in that PR shows the problem:
```
# CHECK-LINE-TABLE: Address Line Column File ISA Discriminator OpIndex Flags
# CHECK-LINE-TABLE-NEXT: ------------------ ------ ------ ------ --- ------------- ------- -------------
# CHECK-LINE-TABLE-NEXT: 0x00000028: 05 DW_LNS_set_column (1)
# CHECK-LINE-TABLE-NEXT: 0x0000002a: 00 DW_LNE_set_address (0x0000000000000000)
# CHECK-LINE-TABLE-NEXT: 0x00000035: 01 DW_LNS_copy
# CHECK-LINE-TABLE-NEXT: 0x0000000000000000 1 1 1 0 0 0 is_stmt
# CHECK-LINE-TABLE-NEXT: 0x00000036: 00 DW_LNE_end_sequence
# CHECK-LINE-TABLE-NEXT: 0x0000000000000000 1 1 1 0 0 0 is_stmt end_sequence
```
Both rows having PC 0x0 is incorrect, and parsers won't be able to parse
them. See more explanation why this is wrong in #154851.
### Design
This PR attempts to fix this by advancing the PC to the next available
Label, and advance to the end of the section if no Label is available.
### Implementation
- `emitDwarfLineEndEntry` will advance PC to the `CurrLabel`
- If `CurrLabel` is null, its probably a fake LineEntry we introduced in
#110192. In that case look for the next Label
- If still not label can be found, use `null` and
`emitDwarfLineEndEntry` is smart enough to advance PC to the end of the
section
- Rename `LastLabel` to `PrevLabel`, "last" can mean "previous" or
"final", this is ambigous.
- Updated the tests to emit a correct label.
### Note
This fix should render #154986 and #154851 obsolete, they were temporary
fixes and don't resolve the root cause.
---------
Signed-off-by: Peter Rong <PeterRong@meta.com>
|
|
Finish making LLVM's implementation of `DW_LNCT_LLVM_source` conform to
the final accepted version of `DW_LNCT_source` from
https://dwarfstd.org/issues/180201.1.html
This is effectively a continuation of a few commits which have moved in
this direction already, including:
* c9cb4fc761cd7 [DebugInfo] Store optional DIFile::Source as pointer
* 87e22bdd2bd6d Allow for mixing source/no-source DIFiles in one CU
This patch:
* Teaches LLParser that there is a distinction between an empty and an
absent "source:" field on DIFile.
* Makes printing the "source:" field in AsmWriter conditional on it
being present, instead of being conditional on it being non-empty.
* Teaches MC to map an empty-but-present source field to "\n" (which is
ambiguous, making the source strings "" and "\n" indistinguishable, but
that's what the DWARF issue specifies).
Add a test for round-tripping an empty source field through
assembler/bitcode.
Extend the test for the actual DWARF generation so it covers all of the
cases (absent, present-but-empty,
present-and-ambiguously-single-newline, present).
|
|
|
|
|
|
(#142253)
This patch addresses an issue where an anonymous DWARF line table symbol
could be inadvertently defined multiple times, leading to an "symbol ''
is already defined" error during assembly or object file emission. This
issue happens for empty functions when
`-emit-func-debug-line-table-offsets` is enabled.
The root cause is the creation of the "end sequence" entry for a DWARF
line table. This entry was sometimes created by copying the last
existing line table entry. If this last entry was a special one (created
for the purpose of marking the position in the line table stream and
having an anonymous symbol attached), the copied end-sequence entry
would also incorrectly reference this same anonymous symbol.
Consequently, when the line table was finally emitted, the DWARF
emission logic would attempt to emit a label for this anonymous symbol
twice, triggering the redefinition error.
The fix ensures that when an end-sequence line table entry is created,
it does not inherit any special stream label from the entry it might
have been based on, thereby preventing the duplicate label emission.
|
|
|
|
Identified with misc-include-cleaner.
|
|
These specify that the value of the given register in the previous frame
is the CFA plus some offset. This isn't very common but can be necessary
if the original value is normally reconstructed from the stack/frame
pointer instead of being saved on the stack and reloaded from there.
|
|
As part of FEAT_PAuthLR, a new DWARF Frame Instruction was introduced,
`DW_CFA_AARCH64_negate_ra_state_with_pc`. This instructs Libunwind that
the PC has been used with the signing instruction. This change includes
three commits
- Libunwind support for the newly introduced DWARF Instruction
- CodeGen Support for the DWARF Instructions
- Reversing the changes made in #96377. Due to
`DW_CFA_AARCH64_negate_ra_state_with_pc`'s requirements to be placed
immediately after the signing instruction, this would mean the CFI
Instruction location was not consistent with the generated location when
not using FEAT_PAuthLR. The commit reverses the changes and makes the
location consistent across the different branch protection options.
While this does have a code size effect, this is a negligible one.
For the ABI information, see here:
https://github.com/ARM-software/abi-aa/blob/853286c7ab66048e4b819682ce17f567b77a0291/aadwarf64/aadwarf64.rst#id23
|
|
As discussed in [the
RFC](https://discourse.llvm.org/t/rfc-extending-llvm-mc-loc-directive-with-labeling-support/79608)
we need a way to create labels in the assembler-generated line section
in order to support the future addition of the
[DW_AT_LLVM_stmt_sequence](https://discourse.llvm.org/t/rfc-new-dwarf-attribute-for-symbolication-of-merged-functions/79434)
attribute.
We have a similar precedent for such behavior with the
[.cfi_label](https://github.com/llvm/llvm-project/pull/97922)
instruction - so we add the `.loc_label THE_LABEL_NAME` instruction
which:
- Terminates the current line sequence in the line section
- Creates a new label with the specified label name in the `.debug_line`
section
|
|
It is almost always simpler to use {} instead of std::nullopt to
initialize an empty ArrayRef. This patch changes all occurrences I could
find in LLVM itself. In future the ArrayRef(std::nullopt_t) constructor
could be deprecated or removed.
|
|
The variable and its comment could lead to confusion (AMDGPU
unnecessarily set it).
|
|
than 2gb (#99263)
Rebase of #84114. I've only included the core changes to frame layout
calculation & CFI generation which sidesteps the regressions found after
merging #84114. Since these changes are a necessary precursor to the
overall fix and are themselves slightly beneficial as CFI is now
generated correctly, I think it is reasonable to merge this first step.
---
For very large stack frames, the offset from the stack pointer to a
local can be more than 2^31 which overflows various `int` offsets in the
frame lowering code.
This patch updates the frame lowering code to calculate the offsets as
64-bit values and fixes CFI to use the corrected sizes.
After this patch, additional work is needed to fix offset truncations in
each target's codegen.
|
|
GNU assembler 2.26 introduced the .cfi_label directive. It does not
expand to any CFI instructions, but defines a label in
.eh_frame/.debug_frame, which can be used by runtime patching code to
locate the FDE. .cfi_label is not allowed for CIE's initial
instructions, and can therefore be used to force the next instruction to
be placed in a FDE instead of a CIE.
In glibc since 2018, sysdeps/riscv/start.S utilizes .cfi_label to force
DW_CFA_undefined to be placed in a FDE. arc/csky/loongarch ports have
copied this use.
```
.cfi_startproc
// DW_CFA_undefined is allowed for CIE's initial instructions.
// Without .cfi_label, gas would place DW_CFA_undefined in a CIE.
.cfi_label .Ldummy
.cfi_undefined ra
.cfi_endproc
```
No CFI instruction is associated with .cfi_label, so the `case
MCCFIInstruction::OpLabel:` code in BOLT is unreachable and onlt to make
-Wswitch happy.
Close #97222
Pull Request: https://github.com/llvm/llvm-project/pull/97922
|
|
We already sort frames by their CIEKey, so we know that we only need to
update the CIE symbol when the CIE key changes. No need for a DenseMap.
|
|
This reverts commit 245491a9f384e4c53421196533c2a2b693efaf8d ("[MC] Disable MCAssembler based constant folding for DwarfDebug")
and cb09b5f3d53e5b7b4452bb3db78dca79fc9b3f17 ("[MC] Disable MCAssembler based constant folding for compact unwind and emitJumpTableEntry").
Checking the relative order of FA and FB is now faster due to
de19f7b6d46f1c38e10e604154f0fdaaffde9ebd ("[MC] Replace fragment ilist with singly-linked lists").
|
|
Fixes: 5ee580bbfb11d781c220c19416c1a97b657e039a
5ee580bbfb11d781c220c19416c1a97b657e039a does not ensure that
UseAssemblerInfoForParsing is re-enabled. This is benign but not good.
|
|
emitJumpTableEntry
Similar to commit 245491a9f384e4c53421196533c2a2b693efaf8d for DwarfDebug.
This completely disables the expensive MCFragment walk code in
`AttemptToFoldSymbolOffsetDifference` when compiling sqlite3.i for
macOS.
In the future, we should try enabling the MCFragment walk only for
constructs like `.if . -_start == 1` and `.subsection a-b` and
remove these `setUseAssemblerInfoForParsing`.
|
|
Commit 6c0665e22174d474050e85ca367424f6e02476be
(https://reviews.llvm.org/D45164) enabled certain constant expression
evaluation for `MCObjectStreamer` at parse time (e.g. `.if` directives,
see llvm/test/MC/AsmParser/assembler-expressions.s).
`getUseAssemblerInfoForParsing` was added to make `clang -c` handling
inline assembly similar to `MCAsmStreamer` (e.g. `llvm-mc -filetype=asm`),
where such expression folding (related to
`AttemptToFoldSymbolOffsetDifference`) is unavailable.
I believe this is overly conservative. We can make some parse-time
expression folding work for `clang -c` even if `clang -S` would still
report an error, a MCAsmStreamer issue (we cannot print `.if`
directives) that should not restrict the functionality of
MCObjectStreamer.
```
% cat b.cc
asm(R"(
.pushsection .text,"ax"
.globl _start; _start: ret
.if . -_start == 1
ret
.endif
.popsection
)");
% gcc -S b.cc && gcc -c b.cc
% clang -S -fno-integrated-as b.cc # succeeded
% clang -c b.cc # succeeded with this patch
% clang -S b.cc # still failed
<inline asm>:4:5: error: expected absolute expression
4 | .if . -_start == 1
| ^
1 error generated.
```
However, removing `getUseAssemblerInfoForParsing` would make
MCDwarfFrameEmitter::Emit (for .eh_frame FDE) slow (~4% compile time
regression for sqlite3.c amalgamation) due to expensive
`AttemptToFoldSymbolOffsetDifference`. For now, make
`UseAssemblerInfoForParsing` false in MCDwarfFrameEmitter::Emit.
Close #62520
Link: https://discourse.llvm.org/t/rfc-clang-assembly-object-equivalence-for-files-with-inline-assembly/78841
Pull Request: https://github.com/llvm/llvm-project/pull/91082
|
|
frames larger than 2gb (#84114)"
This is failing on some EXPENSIVE_CHECKS buildbots
|
|
For very large stack frames, the offset from the stack pointer to a local can be more than 2^31 which overflows various `int` offsets in the frame lowering code.
This patch updates the frame lowering code to calculate the offsets as 64-bit values and resolves the overflows, resulting in the correct codegen for very large frames.
Fixes #48911
|
|
Dwarf 5 allows separating filenames from .debug_line into a separate
.debug_line_str section. The strings are referenced relative to the
start of the .debug_line_str section. Previously, on COFF, the
relocation information instead caused offsets to be relocated to the
base address of the COFF-File. This lead to wrong offsets in linked
COFF (PE) files which caused the debugger to be unable to find the
correct source files.
This patch fixes this problem by making the offsets relative to the
start of the .debug_line_str section instead. There should be no
changes for ELF-Files as everything seems to be working there.
A test is also added to ensure that the correct relocation entries are
emitted.
|
|
This patch replaces uses of StringRef::{starts,ends}with with
StringRef::{starts,ends}_with for consistency with
std::{string,string_view}::{starts,ends}_with in C++20.
I'm planning to deprecate and eventually remove
StringRef::{starts,ends}with.
|
|
The DWARF proposal that the DW_LNCT_LLVM_source extension is based on
(https://dwarfstd.org/issues/180201.1.html) allows to mix source and
non-source files in the same CU by storing an empty string as a
sentinel value.
This patch implements this feature.
Review in https://github.com/llvm/llvm-project/pull/73877
|
|
Note that llvm::support::endianness has been renamed to
llvm::endianness while becoming an enum class as opposed to an
enum. This patch replaces support::{big,little,native} with
llvm::endianness::{big,little,native}.
|
|
Now that llvm::support::endianness has been renamed to
llvm::endianness, we can use the shorter form. This patch replaces
support::endianness with llvm::endianness.
|
|
There was a bug in a code that pre-populated line string for a case where parts
of .debug_line are not processed by BOLT, but copied as raw data. We were not
switching sections. This resulted in parts of the binary being over-written with
debug data.
Reviewed By: maksfb
Differential Revision: https://reviews.llvm.org/D154544
|
|
|
|
to help debug and report better diagnostics for functions like
relaxDwarfCallFrameFragment (D153167).
In MCStreamer, some emitCFI* functions already take a SMLoc argument. Add a
SMLoc argument to the remaining functions that generate a MCCFIInstruction.
|
|
Summary: Currently the crush info is ambiguous when DwarfLineStrSection is null. The patch adds an assertion in the constructor of MCDwarfLineStr when DwarfLineStrSection is null.
Reviewed By: shchenz
Differential Revision: https://reviews.llvm.org/D149121
|
|
raw_ostream. NFC
Similar to 49488490d195591bfc90daef111cd7293f8c80aa.
Remove MCDwarfFrameEmitter::EmitAdvanceLoc which is only called once.
|
|
Similar to D145791: most call sites need a SmallString, but have to provide a
raw_svector_ostream wrapper with unneeded abstraction and overhead:
raw_ostream::write =(inlinable)=> flush_tied_then_write (unneeded TiedStream check) =(virtual function call)=> raw_svector_ostream::write_impl ==> SmallVector append(ItTy in_start, ItTy in_end) (range; less efficient then push_back).
Just use SmallVectorImpl to simplify and optimize code. Unfortunately most call
sites use SmallString, so we have to use SmallVectorImpl<char> instead of
<uint8_t> to avoid large refactoring.
|
|
.debug_frame intrinsic is used
The .cfi_sections .debug_frame intrinsic is used to emit .debug_frame
section. This directive tells the assembler to write out a section of
debug frame data. AArch64 is a platform where eh_frame is not needed for
unwind information. Unfortunately, that means that even when the
.cfi_sections .debug_frame intrinsic is used, the compiler skips
emitting the CIE's and FDE's in the debug_frame section. This patch
address that issue by making sure that the emission of CIE's and FDE's
are only skipped if the unwind information does not require a
debug_frame section and is a platform where the eh_frame can be skipped.
Differential Revision: https://reviews.llvm.org/D147980
|
|
Use deduction guides instead of helper functions.
The only non-automatic changes have been:
1. ArrayRef(some_uint8_pointer, 0) needs to be changed into ArrayRef(some_uint8_pointer, (size_t)0) to avoid an ambiguous call with ArrayRef((uint8_t*), (uint8_t*))
2. CVSymbol sym(makeArrayRef(symStorage)); needed to be rewritten as CVSymbol sym{ArrayRef(symStorage)}; otherwise the compiler is confused and thinks we have a (bad) function prototype. There was a few similar situation across the codebase.
3. ADL doesn't seem to work the same for deduction-guides and functions, so at some point the llvm namespace must be explicitly stated.
4. The "reference mode" of makeArrayRef(ArrayRef<T> &) that acts as no-op is not supported (a constructor cannot achieve that).
Per reviewers' comment, some useless makeArrayRef have been removed in the process.
This is a follow-up to https://reviews.llvm.org/D140896 that introduced
the deduction guides.
Differential Revision: https://reviews.llvm.org/D140955
|
|
|
|
.cfi_sections .debug_frame directive is used."
This reverts commit d2cbdb6bef31bdc3254daf57148225ea4b34520c.
This is because we are seeing linker crashes in the internal apple bots.
|
|
.debug_frame directive is used.
Differential Revision: https://reviews.llvm.org/D139663
|
|
.cfi_sections .debug_frame directive is used."
This reverts commit 28edf3349bd1d595270c17ec73e49999175f1212.
This is because:
The Buildbot has detected a failed build on builder llvm-clang-x86_64-sie-ubuntu-fast while building llvm.
Full details are available at:
https://lab.llvm.org/buildbot#builders/139/builds/32856
Worker for this Build: sie-linux-worker
Blamelist:
Shubham Sandeep Rastogi <srastogi22@apple.com>
BUILD FAILED: 40459 expected passes 83 expected failures 26251 unsupported tests 1 unexpected failures (failure)
Step 6 (test-build-unified-tree-check-all) failure: 40459 expected passes 83 expected failures 26251 unsupported tests 1 unexpected failures (failure)
******************** TEST 'LLVM :: DebugInfo/debugframeinfo.s' FAILED ********************
Script:
--
: 'RUN: at line 1'; /home/buildbot/buildbot-root/llvm-clang-x86_64-sie-ubuntu-fast/build/bin/llvm-mc -filetype=obj -triple=arm64-apple-darwin22.1.0 /home/buildbot/buildbot-root/llvm-project/llvm/test/DebugInfo/debugframeinfo.s -o /home/buildbot/buildbot-root/llvm-clang-x86_64-sie-ubuntu-fast/build/test/DebugInfo/Output/debugframeinfo.s.tmp.o
: 'RUN: at line 2'; /home/buildbot/buildbot-root/llvm-clang-x86_64-sie-ubuntu-fast/build/bin/llvm-dwarfdump -debug-frame /home/buildbot/buildbot-root/llvm-clang-x86_64-sie-ubuntu-fast/build/test/DebugInfo/Output/debugframeinfo.s.tmp.o | /home/buildbot/buildbot-root/llvm-clang-x86_64-sie-ubuntu-fast/build/bin/FileCheck /home/buildbot/buildbot-root/llvm-project/llvm/test/DebugInfo/debugframeinfo.s
--
Exit Code: 1
Command Output (stderr):
--
/home/buildbot/buildbot-root/llvm-clang-x86_64-sie-ubuntu-fast/build/bin/llvm-mc: error: unable to get target for 'arm64-apple-darwin22.1.0', see --version and --triple.
|
|
.debug_frame directive is used.
Differential Revision: https://reviews.llvm.org/D139663
|
|
|
|
https://discourse.llvm.org/t/deprecating-llvm-optional-x-hasvalue-getvalue-getvalueor/63716
|
|
|
|
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
|
|
Differential Revision: https://reviews.llvm.org/D138674
|
|
Before this, we would incorrectly coalesce CIE for frames with and
without stack MTE.
Reviewed By: eugenis
Differential Revision: https://reviews.llvm.org/D135639
|
|
Reviewed By: eugenis
Differential Revision: https://reviews.llvm.org/D135638
|
|
LLVM contains a helpful function for getting the size of a C-style
array: `llvm::array_lengthof`. This is useful prior to C++17, but not as
helpful for C++17 or later: `std::size` already has support for C-style
arrays.
Change call sites to use `std::size` instead.
Differential Revision: https://reviews.llvm.org/D133429
|
|
(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
|
