127 Commits

Author SHA1 Message Date
AmirHossein PashaeeHir
c44c142afc
[NFC] Separate UnwindTable from DebugFrame into a different type (#142521)
By separating the Unwind table into a different file, this functionality
can be a part of the DWARF library with no dependency on MC, which makes
it usable in the MC layer.

This is a continuation of
[PR#14520](https://github.com/llvm/llvm-project/pull/142520).
2025-07-08 11:33:58 -07:00
Sterling-Augustine
23f1ba3ee4
Reapply "[NFC][DebugInfo][DWARF] Create new low-level dwarf library (#… (#145959) (#146112)
Reapply "[NFC][DebugInfo][DWARF] Create new low-level dwarf library (#…
(#145959)
    
This reapplies cbf781f0bdf2f680abbe784faedeefd6f84c246e, with fixes for
the shared-library build and the unconventional sanitizer-runtime build.

Original Description:

This is the culmination of a series of changes described in [1].
    
Although somewhat large by line count, it is almost entirely mechanical,
creating a new library in DebugInfo/DWARF/LowLevel. This new library has
very minimal dependencies, allowing it to be used from more places than
the normal DebugInfo/DWARF library--in particular from MC.
    
1.
https://discourse.llvm.org/t/rfc-debuginfo-dwarf-refactor-into-to-lower-and-higher-level-libraries/86665/2
2025-06-27 11:05:49 -07:00
Sterling-Augustine
5d03e7a204
Revert "[NFC][DebugInfo][DWARF] Create new low-level dwarf library (#… (#145959)
…145081)"

This reverts commit cbf781f0bdf2f680abbe784faedeefd6f84c246e.

Breaks a couple of buildbots.
2025-06-26 13:09:20 -07:00
Sterling-Augustine
cbf781f0bd
[NFC][DebugInfo][DWARF] Create new low-level dwarf library (#145081)
This is the culmination of a series of changes described in [1].
    
Although somewhat large by line count, it is almost entirely mechanical,
creating a new library in DebugInfo/DWARF/LowLevel. This new library has
very minimal dependencies, allowing it to be used from more places than
the normal DebugInfo/DWARF library--in particular from MC.
    
I am happy to put it in another location, or to structure it differently
if that makes sense. Some have suggested in BinaryFormat, but it is not
a great fit there. But if that makes more sense to the reviewers, I can
do that.
 
Another possibility would be to use pass-through headers to allow
clients who don't care to depend only on DebugInfo/DWARF. This would be
a much less invasive change, and perhaps easier for clients. But also a
system that hides details.

Either way, I'm open.

1.
https://discourse.llvm.org/t/rfc-debuginfo-dwarf-refactor-into-to-lower-and-higher-level-libraries/86665/2
2025-06-26 11:23:46 -07:00
AmirHossein PashaeeHir
b9d1642423
[NFC] Remove UnwindTable dependency on CIE, and FDE (#142520)
This PR is in the direction of separating Unwind table from FDE, and CIE
that depends on llvm/Object.

To separate, first the runtime dependencies have to be removed, which
this commit does that.
This is similar to
[1](https://github.com/llvm/llvm-project/pull/140096),
[2](https://github.com/llvm/llvm-project/pull/139175), and
[3](https://github.com/llvm/llvm-project/pull/139326).
2025-06-23 23:15:18 -07:00
Sterling-Augustine
628274dadf
[NFC] Extract Printing portions of DWARFCFIProgram to new files (#143762)
CFIPrograms' most common uses are within debug frames, but it is not
their only use. For example, some assembly writers encode them by hand
into .cfi_escape directives. This PR extracts printing code for them
into its own files, which avoids the need for the main class to depend
on DWARFUnit, sections, and similar.

One in a series of NFC DebugInfo/DWARF refactoring changes to layer it
more cleanly, so that binary CFI parsing can be used from low-level
code, (such as byte strings created via .cfi_escape) without circular
dependencies. The final goal is to make a more limited dwarf library
usable from lower-level code.

More information can be found at
https://discourse.llvm.org/t/rfc-debuginfo-dwarf-refactor-into-to-lower-and-higher-level-libraries/86665
2025-06-17 16:35:47 -07:00
Sterling-Augustine
474db6a852
[NFC] Separate high-level-dependent portions of DWARFExpression (revised) (#143170)
(Revised version of a previous, unreviewed, PR.)

Move all expression verification into its only client: DWARFVerifier.
Move all printing code (which was a mix of static and member functions)
into a separate class.

This is one in a series of refactoring PRs to separate dwarf
functionality into lower-level pieces usable without object files and
sections at build time. The code is already written this way via various
"if (section == nullptr)" and similar conditionals. So the functionality
itself is needed and exists, but only as a runtime feature. The goal of
these refactors is to remove the build-time dependencies, which will
allow the existing functionality to be used from lower-level parts of
the compiler. Particularly from lib/MC/.... More information at:


https://discourse.llvm.org/t/rfc-debuginfo-dwarf-refactor-into-to-lower-and-higher-level-libraries/86665
2025-06-09 16:32:40 -07:00
Sterling-Augustine
1a0f284dea
[NFC] Extract DWARFCFIProgram into separate files (#139326)
CFIPrograms' most common uses are within debug frames, but it is not
their only use. For example, some assembly writers encode them by hand
into .cfi_escape directives. This PR extracts code for them into its own
files, setting them up to be evaluated from outside debug frames
themselves.

One in a series of NFC DebugInfo/DWARF refactoring changes to layer it
more cleanly, so that binary CFI parsing can be used from low-level
code, (such as byte strings created via .cfi_escape) without circular
dependencies. The final goal is to make a more limited dwarf library
usable from lower-level code.
2025-06-02 15:33:28 -07:00
Kazu Hirata
0060c54e0d
[DebugInfo] Remove unused includes (NFC) (#116551)
Identified with misc-include-cleaner.
2024-11-17 10:37:33 -08:00
Jack Styles
86f76c3b17
[AArch64][Libunwind] Add Support for FEAT_PAuthLR DWARF Instruction (#112171)
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:
853286c7ab/aadwarf64/aadwarf64.rst (id23)
2024-10-28 08:22:38 +00:00
Igor Kudrin
fe84764724
[DWARF] Dump an updated location for DW_CFA_advance_loc* (#84274)
When dumping FDEs, `readelf` prints new location values after
`DW_CFA_advance_loc(*)` instructions, which looks quite convenient:

```
> readelf -wf test.o
...
... FDE ... pc=0000000000000030..0000000000000064
  DW_CFA_advance_loc: 4 to 0000000000000034
  ...
  DW_CFA_advance_loc: 4 to 0000000000000038
...
```

This patch makes `llvm-dwarfdump` and `llvm-readobj` do the same.
2024-03-08 07:34:36 +07:00
Igor Kudrin
0cd7942c7f
[llvm-dwarfdump] Fix parsing DW_CFA_AARCH64_negate_ra_state (#84128)
The saved state of the AARCH64_DWARF_PAUTH_RA_STATE register was not
updated, so `llvm-dwarfdump` continued to dump it as `reg34=1` even if
the correct value is `0`:

```
> llvm-dwarfdump -v test.o
...
0000002c 00000024 00000030 FDE cie=00000000 pc=00000030...00000064
  Format:       DWARF32
  DW_CFA_advance_loc: 4
  DW_CFA_AARCH64_negate_ra_state:
  DW_CFA_advance_loc: 4
  DW_CFA_def_cfa_offset: +16
  DW_CFA_offset: W30 -16
  DW_CFA_remember_state:
  DW_CFA_advance_loc: 16
  DW_CFA_def_cfa_offset: +0
  DW_CFA_advance_loc: 4
  DW_CFA_AARCH64_negate_ra_state:
  DW_CFA_restore: W30
  DW_CFA_advance_loc: 4
  DW_CFA_restore_state:
  DW_CFA_advance_loc: 12
  DW_CFA_def_cfa_offset: +0
  DW_CFA_advance_loc: 4
  DW_CFA_AARCH64_negate_ra_state:
  DW_CFA_restore: W30
  DW_CFA_nop:

  0x30: CFA=WSP
  0x34: CFA=WSP: reg34=1
  0x38: CFA=WSP+16: W30=[CFA-16], reg34=1
  0x48: CFA=WSP: W30=[CFA-16], reg34=1
  0x4c: CFA=WSP: reg34=1               <--- should be '=0'
  0x50: CFA=WSP+16: W30=[CFA-16], reg34=1
  0x5c: CFA=WSP: W30=[CFA-16], reg34=1
  0x60: CFA=WSP: reg34=1               <--- should be '=0'
```
2024-03-08 07:34:20 +07:00
Alexis Engelke
7cf99347d4 [DWARF] Store CFA value on DW_CFA_remember_state
Previously, CFA_remember_state stored only the register locations but ignored the CFA value. This needs also to be remembered and restored for correct behavior. The problem occurs, e.g., on functions with multiple epilogues, where the CFA value after the first epilogue is becomes wrong.

Reviewed By: #debug-info, MaskRay

Differential Revision: https://reviews.llvm.org/D140338
2023-01-04 13:51:14 -08:00
Shubham Sandeep Rastogi
617ed4f061 Remove the dependency between lib/DebugInfoDWARF and MC.
Differential Revision: https://reviews.llvm.org/D134817
2022-12-15 18:23:27 -08:00
Shubham Sandeep Rastogi
4283cfdc11 Revert "Remove the dependency between lib/DebugInfoDWARF and MC."
This reverts commit 7dde94251e1c9e4634f5d51d41f2d4a191258fb3.

Because of test failures:

  lldb-shell :: SymbolFile/DWARF/x86/DW_AT_loclists_base.s
  lldb-shell :: SymbolFile/DWARF/x86/debug_loc.s
  lldb-shell :: SymbolFile/DWARF/x86/debug_loc_and_loclists.s
  lldb-shell :: SymbolFile/DWARF/x86/debug_loclists-dwo.s
  lldb-shell :: SymbolFile/DWARF/x86/debug_loclists-dwp.s
  lldb-shell :: SymbolFile/DWARF/x86/dwp.s
  lldb-shell :: SymbolFile/DWARF/x86/unused-inlined-params.test
  lldb-shell :: SymbolFile/NativePDB/inline_sites.test
  lldb-shell :: SymbolFile/NativePDB/local-variables-registers.s
  lldb-shell :: SymbolFile/NativePDB/nested-blocks-same-address.s
2022-12-14 18:32:18 -08:00
Shubham Sandeep Rastogi
7dde94251e Remove the dependency between lib/DebugInfoDWARF and MC.
Differential Revision: https://reviews.llvm.org/D134817
2022-12-14 18:16:46 -08:00
Kazu Hirata
934942c033 [llvm] Don't include Optional.h (NFC)
These source files no longer use Optional<T>, so they do not need to
include Optional.h.

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-06 22:34:50 -08:00
Fangrui Song
89fab98e88 [DebugInfo] llvm::Optional => std::optional
https://discourse.llvm.org/t/deprecating-llvm-optional-x-hasvalue-getvalue-getvalueor/63716
2022-12-05 00:09:22 +00:00
Fangrui Song
f4c16c4473 [MC] llvm::Optional => std::optional
https://discourse.llvm.org/t/deprecating-llvm-optional-x-hasvalue-getvalue-getvalueor/63716
2022-12-04 21:36:08 +00:00
Kazu Hirata
110115993c [DebugInfo] Use std::nullopt instead of None (NFC)
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-02 21:11:39 -08:00
Kazu Hirata
d53a3dd450 [DWARF] Use std::optional in DWARFDebugFrame.cpp (NFC)
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-25 11:41:44 -08:00
Shubham Sandeep Rastogi
f491b898c5 Revert "Remove the dependency between lib/DebugInfoDWARF and MC."
This reverts commit d96ade00c3c96bd451c60e34a17e613cdd5fdc38.
2022-10-06 14:58:34 -07:00
Shubham Sandeep Rastogi
d96ade00c3 Remove the dependency between lib/DebugInfoDWARF and MC.
This patch had to be reverted because on gcc 7.5.0 we see an error converting from std::unique_ptr<MCRegisterInfo> to Expected<std::unique_ptr<MCRegisterInfo>> as the return type for the function createRegInfo. This has now been fixed.
2022-10-06 14:46:01 -07:00
Shubham Sandeep Rastogi
870b74d590 Revert "Remove the dependency between lib/DebugInfoDWARF and MC."
This reverts commit 0008990479a2daf587c2a4f274384b2fb87247fb.
2022-10-06 09:30:46 -07:00
Shubham Sandeep Rastogi
0008990479 Remove the dependency between lib/DebugInfoDWARF and MC.
Differential Revision: https://reviews.llvm.org/D134817
2022-10-06 09:25:57 -07:00
Kazu Hirata
e0e687a615 [llvm] Don't use Optional::hasValue (NFC) 2022-06-20 10:38:12 -07:00
Florian Mayer
a2695c3fe1 [DWARF] Support 'G' in dwarf parser
Reviewed By: MaskRay

Differential Revision: https://reviews.llvm.org/D127171
2022-06-08 14:27:51 -07:00
Florian Mayer
0d54a874ee Revert "[DWARF] Support 'G' in dwarf parser"
This reverts commit 4c71c3386c5c79560517a22e75938c9951f8de68.
2022-06-08 13:53:00 -07:00
Florian Mayer
4c71c3386c [DWARF] Support 'G' in dwarf parser
Reviewed By: MaskRay

Differential Revision: https://reviews.llvm.org/D127171
2022-06-08 12:39:53 -07:00
Florian Mayer
f60875254b [DWARF] Show which augmentation character was unrecognized.
Reviewed By: MaskRay

Differential Revision: https://reviews.llvm.org/D127003
2022-06-03 15:35:33 -07:00
serge-sans-paille
290e482342 Cleanup LLVMDWARFDebugInfo
As usual with that header cleanup series, some implicit dependencies now need to
be explicit:

llvm/DebugInfo/DWARF/DWARFContext.h no longer includes:
- "llvm/DebugInfo/DWARF/DWARFAcceleratorTable.h"
- "llvm/DebugInfo/DWARF/DWARFCompileUnit.h"
- "llvm/DebugInfo/DWARF/DWARFDebugAbbrev.h"
- "llvm/DebugInfo/DWARF/DWARFDebugAranges.h"
- "llvm/DebugInfo/DWARF/DWARFDebugFrame.h"
- "llvm/DebugInfo/DWARF/DWARFDebugLoc.h"
- "llvm/DebugInfo/DWARF/DWARFDebugMacro.h"
- "llvm/DebugInfo/DWARF/DWARFGdbIndex.h"
- "llvm/DebugInfo/DWARF/DWARFSection.h"
- "llvm/DebugInfo/DWARF/DWARFTypeUnit.h"
- "llvm/DebugInfo/DWARF/DWARFUnitIndex.h"

Plus llvm/Support/Errc.h not included by a bunch of llvm/DebugInfo/DWARF/DWARF*.h files

Preprocessed lines to build llvm on my setup:
after: 1065629059
before: 1066621848

Which is a great diff!

Discourse thread: https://discourse.llvm.org/t/include-what-you-use-include-cleanup
Differential Revision: https://reviews.llvm.org/D119723
2022-02-15 09:16:03 +01:00
RamNalamothu
167e7afcd5 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
2021-06-14 08:51:50 +05:30
Simon Pilgrim
35a12023f3 DWARFDebugFrame.cpp - remove unused <string> include. NFCI. 2021-06-13 15:19:24 +01:00
RamNalamothu
223852d76f [DebugInfo] UnwindTable::create() should not add empty rows to CFI unwind table
UnwindTable::parseRows() may return successfully if the CFIProgram has either
no CFI instructions or only DW_CFA_nop instructions and the UnwindRow return
argument will be empty. But currently, the callers are not checking for this case
which is leading to incorrect dumps in the unwind tables in such cases i.e.

  CFA=unspecified

Reviewed By: clayborg

Differential Revision: https://reviews.llvm.org/D101892
2021-05-08 10:19:02 +05:30
Rafael Auler
7a3e664db5 [DebugInfo] Do not error on unsupported CIE version
D81469 introduced a check to error on CIE version different
than 1 for eh_frame, but older compilers mistakenly create binaries
with this version set to 3 for DWARF4 or 4 to DWARF5. Move the check
to dump time instead of eh_frame parse time, so we can be tolerant
with older binaries.

Reviewed By: aprantl

Differential Revision: https://reviews.llvm.org/D97830
2021-03-08 19:39:08 -08:00
Yang Fan
e5f258cb03
[NFC][DebugInfo] Fix Wreturn-type gcc warning
GCC warning:
```
/llvm-project/llvm/lib/DebugInfo/DWARF/DWARFDebugFrame.cpp: In member function ‘llvm::Expected<long unsigned int> llvm::dwarf::CFIProgram::Instruction::getOperandAsUnsigned(const llvm::dwarf::CFIProgram&, uint32_t) const’:
/llvm-project/llvm/lib/DebugInfo/DWARF/DWARFDebugFrame.cpp:425:1: warning: control reaches end of non-void function [-Wreturn-type]
  425 | }
      | ^
/llvm-project/llvm/lib/DebugInfo/DWARF/DWARFDebugFrame.cpp: In member function ‘llvm::Expected<long int> llvm::dwarf::CFIProgram::Instruction::getOperandAsSigned(const llvm::dwarf::CFIProgram&, uint32_t) const’:
/llvm-project/llvm/lib/DebugInfo/DWARF/DWARFDebugFrame.cpp:477:1: warning: control reaches end of non-void function [-Wreturn-type]
  477 | }
      | ^
```
2021-01-29 11:42:23 +08:00
Greg Clayton
f8122d3532 Add the ability to extract the unwind rows from DWARF Call Frame Information.
This patch adds the ability to evaluate the state machine for CIE and FDE unwind objects and produce a UnwindTable with all UnwindRow objects needed to unwind registers. It will also dump the UnwindTable for each CIE and FDE when dumping DWARF .debug_frame or .eh_frame sections in llvm-dwarfdump or llvm-objdump. This allows users to see what the unwind rows actually look like for a given CIE or FDE instead of just seeing a list of opcodes.

This patch adds new classes: UnwindLocation, RegisterLocations, UnwindRow, and UnwindTable.

UnwindLocation is a class that describes how to unwind a register or Call Frame Address (CFA).

RegisterLocations is a class that tracks registers and their UnwindLocations. It gets populated when parsing the DWARF call frame instruction opcodes for a unwind row. The registers are mapped from their register numbers to the UnwindLocation in a map.

UnwindRow contains the result of evaluating a row of DWARF call frame instructions for the CIE, or a row from a FDE. The CIE can produce a set of initial instructions that each FDE that points to that CIE will use as the seed for the state machine when parsing FDE opcodes. A UnwindRow for a CIE will not have a valid address, whille a UnwindRow for a FDE will have a valid address.

The UnwindTable is a class that contains a sorted (by address) vector of UnwindRow objects and is the result of parsing all opcodes in a CIE, or FDE. Parsing a CIE should produce a UnwindTable with a single row. Parsing a FDE will produce a UnwindTable with one or more UnwindRow objects where all UnwindRow objects have valid addresses. The rows in the UnwindTable will be sorted from lowest Address to highest after parsing the state machine, or an error will be returned if the table isn't sorted. To parse a UnwindTable clients can use the following methods:

    static Expected<UnwindTable> UnwindTable::create(const CIE *Cie);
    static Expected<UnwindTable> UnwindTable::create(const FDE *Fde);

A valid table will be returned if the DWARF call frame instruction opcodes have no encoding errors. There are a few things that can go wrong during the evaluation of the state machine and these create functions will catch and return them.

Differential Revision: https://reviews.llvm.org/D89845
2021-01-28 13:39:17 -08:00
Simon Pilgrim
7396f720f9 [DebugInfo] Remove some unused includes. NFCI.
Mainly removing a lot of <vector> includes from files that don't explicitly use std::vector
2021-01-28 11:21:35 +00:00
David Blaikie
0ec5baa132 llvm-dwarfdump: Support verbose printing DW_OP_convert to print the CU local offset before the resolved absolute offset 2020-10-23 18:50:15 -07:00
Greg Clayton
a4b842e294 Show register names in DWARF unwind info.
Register context information was already being passed into the DWARFDebugFrame code that dumps unwind information but it wasn't being used. This change adds the ability to dump registers names of a valid MC register context was passed in and if it knows about the register. Updated the tests to use the newly returned register names.

Differential Revision: https://reviews.llvm.org/D88767
2020-10-05 15:34:33 -07:00
Fangrui Song
3ab0f53ef3 [DebugInfo] Respect relocations when decoding DW_EH_PE_sdata4 & DW_EH_PE_sdata8 and support R_ARM_REL32
The addresses in llvm-dwarfdump --eh-frame output for object files are closer to readelf -wf output now.
2020-07-18 09:00:50 -07:00
Georgii Rymar
bee8cdcabd [DebugInfo/DWARF] - Test invalid CFI opcodes properly and refine related CFIProgram::parse code.
There are following issues with `CFIProgram::parse` code:

1) Invalid CFI opcodes were never tested. And currently a test would fail
when the `LLVM_ENABLE_ABI_BREAKING_CHECKS` is enabled. It happens because
the `DataExtractor::Cursor C` remains unchecked when the
"Invalid extended CFI opcode" error is reported:

```
.eh_frame section at offset 0x1128 address 0x0:
Program aborted due to an unhandled Error:
Error value was Success. (Note: Success values must still be checked prior to being destroyed).
```

2) It is impossible to reach the "Invalid primary CFI opcode" error with the current code.
There are 3 possible primary opcode values and all of them are handled. Hence this error
should be replaced with llvm_unreachable.

3) Errors currently reported are upper-case.

This patch refines the code in the `CFIProgram::parse` method to fix all issues mentioned
and adds unit tests for all possible invalid extended CFI opcodes.

Differential revision: https://reviews.llvm.org/D82868
2020-07-08 12:10:23 +03:00
Georgii Rymar
1e820e82b1 [DebugInfo/DWARF] - Do not hang when CFI are truncated.
Currently when the .eh_frame section is truncated so that
CFI instructions can't be read, it is possible to enter
an infinite loop.

It happens because `CFIProgram::parse` does not handle errors properly.
This patch fixes the issue.

Differential revision: https://reviews.llvm.org/D82017
2020-06-23 14:39:24 +03:00
Georgii Rymar
66fb3c39cb [DebugInfo/DWARF] - Report .eh_frame sections of version != 1.
Specification (https://refspecs.linuxbase.org/LSB_5.0.0/LSB-Core-generic/LSB-Core-generic/ehframechpt.html#AEN1349)
says that the value of Version field for .eh_frame should be 1.

Though we accept other values and might perform an attempt to read
it as a .debug_frame because of that, what is wrong.

This patch adds a version check.

Differential revision: https://reviews.llvm.org/D81469
2020-06-16 15:46:26 +03:00
Igor Kudrin
4933ab2ccb [DebugInfo] Report the format of call frame information entries [6/10]
Differential Revision: https://reviews.llvm.org/D80523
2020-06-02 17:55:30 +07:00
Georgii Rymar
84c6433586 [DebugInfo] - Fix typo in comment. NFC.
I've forgot to address this bit when landed D80476.
2020-05-27 12:21:19 +03:00
Georgii Rymar
2e365ca2f7 [DebugInfo/llvm-objdump] - Print "ZERO terminator" for terminator entries when dumping .eh_frame.
A CIE with the Length == 0 is a terminator:
https://refspecs.linuxfoundation.org/LSB_5.0.0/LSB-Core-generic/LSB-Core-generic/ehframechpt.html

And GNU objdump recognizes them and prints the following for such entries:

"00000000 ZERO terminator"

This patch teaches llvm-objdump to do the same. I had to update tests to use
"CHECK-NEXT" too.

(Note: it looks perhaps not right that printing is done inside the DebugInfo library,
I'd expect to see the change in the llvm-objdump's code somewhere instead,
but that is how it done atm).

Differential revision: https://reviews.llvm.org/D80476
2020-05-26 12:52:42 +03:00
Georgii Rymar
2569787e44 [DebugInfo] - Fix multiple issues in DWARFDebugFrame::parse().
I've noticed an issue with "Data.getRelocatedValue(...)" call.

it might silently ignore an error when a content is truncated.
That leads to an infinite loop in the code (e.g. llvm-readobj hangs).

After fixing the issue I've found that actually we always tried
to read past the end of a section, even when a content was valid.
It happened because the terminator CIE (a CIE with the length == 0)
was never handled. At first I've tried just to stop adding the terminator
entry (and return), but it does not seem to be correct, because tools like
llvm-objdump might want to print something for such entries
(see comments in the code and test cases).

This patch fixes issues mentioned, provides new test cases for
both llvm-readobj and lib/DebugInfo and adds FIXMEs to existent
test cases related.

Differential revision: https://reviews.llvm.org/D80299
2020-05-26 12:13:13 +03:00
Georgii Rymar
710d9d66f8 [DebugInfo] - DWARFDebugFrame: do not call abort() on errors.
Imagine we have a broken .eh_frame.
Below is a possible sample output of llvm-readelf:

```
...
    entry 2 {
      initial_location: 0x10f5
      address: 0x2080
    }
  }
}
.eh_frame section at offset 0x2028 address 0x2028:
LLVM ERROR: Parsing entry instructions at 0 failed
PLEASE submit a bug report to https://bugs.llvm.org/ and include the crash backtrace.
Stack dump:
0.  Program arguments: /home/umb/LLVM/LLVM/llvm-project/build/bin/llvm-readelf -a 1
 #0 0x000055f4a2ff5a1a llvm::sys::PrintStackTrace(llvm::raw_ostream&) (/home/umb/LLVM/LLVM/llvm-project/build/bin/llvm-readelf+0x2b9a1a)
...
#15 0x00007fdae5dc209b __libc_start_main /build/glibc-B9XfQf/glibc-2.28/csu/../csu/libc-start.c:342:3
#16 0x000055f4a2db746a _start (/home/umb/LLVM/LLVM/llvm-project/build/bin/llvm-readelf+0x7b46a)
Aborted
```

I.e. it calls abort(), suggests to submit a bug report and exits with the code 134.
This patch changes the logic to propagate errors to callers.
This fixes the behavior for llvm-dwarfdump, llvm-readobj and other possible tools.

Differential revision: https://reviews.llvm.org/D79165
2020-05-15 13:05:35 +03:00
Fangrui Song
befbc99a7f Reland D79501 "[DebugInfo] Fix handling DW_OP_call_ref in DWARF64 units."
With a fix to uninitialized EndOffset.

DW_OP_call_ref is the only operation that has an operand which depends
on the DWARF format. The patch fixes handling that operation in DWARF64
units.

Differential Revision: https://reviews.llvm.org/D79501
2020-05-08 09:35:54 -07:00