aboutsummaryrefslogtreecommitdiff
path: root/llvm/unittests/DebugInfo/DWARF/DWARFDebugLineTest.cpp
AgeCommit message (Collapse)AuthorFilesLines
2025-02-06[DebugInfo][DWARF] Utilize DW_AT_LLVM_stmt_sequence attr in line table ↵alx321-1/+114
lookups (#123391) **Summary** Add support for filtering line table entries based on `DW_AT_LLVM_stmt_sequence` attribute when looking up address ranges. This ensures that line entries are correctly attributed to their corresponding functions, even when multiple functions share the same address range due to optimizations. **Background** In https://github.com/llvm/llvm-project/pull/110192 we added support to clang to generate the `DW_AT_LLVM_stmt_sequence` attribute for `DW_TAG_subprogram`'s. Corresponding RFC: [New DWARF Attribute for Symbolication of Merged Functions](https://discourse.llvm.org/t/rfc-new-dwarf-attribute-for-symbolication-of-merged-functions/79434) The `DW_AT_LLVM_stmt_sequence` attribute allows accurate attribution of line number information to their corresponding functions, even in scenarios where functions are merged or share the same address space due to optimizations like Identical Code Folding (ICF) in the linker. **Implementation Details** The patch modifies `DWARFDebugLine::lookupAddressRange` to accept an optional DWARFDie parameter. When provided, the function checks if the `DIE` has a `DW_AT_LLVM_stmt_sequence` attribute. This attribute contains an offset into the line table that marks where the line entries for this DIE's function begin. If the attribute is present, the function filters the results to only include line entries from the sequence that starts at the specified offset. This ensures that even when multiple functions share the same address range, we return only the line entries that actually belong to the function represented by the DIE. The implementation: - Adds an optional DWARFDie parameter to lookupAddressRange - Extracts the `DW_AT_LLVM_stmt_sequence` offset if present - Modifies the address range lookup logic to filter sequences based on their offset - Returns only line entries from the matching sequence
2024-09-13[llvm][unittests] Don't call raw_string_ostream::flush() (NFC)JOE19941-2/+0
raw_string_ostream::flush() is essentially a no-op (also specified in docs). Don't call it in tests that aren't meant to test 'raw_string_ostream' itself. p.s. remove a few redundant calls to raw_string_ostream::str()
2024-02-22[lldb][llvm] Return an error instead of crashing when parsing a line table ↵Greg Clayton1-1/+3
prologue. (#80769) We recently ran into some bad DWARF where the `DW_AT_stmt_list` of many compile units was randomly set to invalid values and was causing LLDB to crash due to an assertion about address sizes not matching. Instead of asserting, we should return an appropriate recoverable `llvm::Error`.
2023-11-10[AIX] Enable tests relating to 64-bit XCOFF object files (#71814)Jake Egan1-140/+15
We now have 64-bit XCOFF object file support, so these tests can be enabled again. However, some tests still fail due to unsupported debug sections, so I cleaned up their comments.
2023-07-12[DWARF] Allow op-index in line number programsDavid Stenberg1-28/+192
This extends DWARFDebugLine to properly parse line number programs with maximum_operations_per_instruction > 1 for VLIW targets. No functions that use that parsed output to retrieve line information have been extended to support multiple op-indexes. This means that when retrieving information for an address with multiple op-indexes, e.g. when using llvm-addr2line, the penultimate row for that address will be used, which in most cases is the row for the second largest op-index. This will be addressed in further changes, but this patch at least allows us to correctly parse such line number programs, with a warning saying that the line number information may be incorrect (incomplete). Reviewed By: StephenTozer Differential Revision: https://reviews.llvm.org/D152536
2023-07-12[DWARF] Add printout for op-indexDavid Stenberg1-5/+7
This is a preparatory patch for extending DWARFDebugLine to properly parse line number programs with maximum_operations_per_instruction > 1 for VLIW targets. Add some scaffolding for handling op-index in line number programs, and add printouts for that in the table. As this affects a lot of tests, this is done in a separate commit to get a cleaner review for the actual op-index implementation. Verbose printouts are not present in many tests, and adding op-index to those will require a bit more code changes, so that is done in the actual implementation patch. Reviewed By: StephenTozer Differential Revision: https://reviews.llvm.org/D152535
2022-05-24Exposes interface to free up caching data structure in DWARFDebugLine and ↵Hyoun Kyu Cho1-0/+76
DWARFUnit for memory management This is minimum changes extracted from https://reviews.llvm.org/D78950. The old patch tried to add LRU eviction of caching data structure. Due to multiple layers of interfaces that users could be using, it was not clear where to put the functionality. While we work out on where to put that functionality, it'll be great to add this minimum interface change so that the user could implement their own memory management. More specifically: * Add a clearLineTable method for DWARFDebugLine which erases the given offset from the LineTableMap. * DWARFDebugContext adds the clearLineTableForUnit method that leverages clearLineTable to remove the object corresponding to a given compile unit, for memory management purposes. When it is referred to again, the line table object will be repopulated. Reviewed By: dblaikie Differential Revision: https://reviews.llvm.org/D90006
2021-12-22[unittest][DebugInfo/DWARF] Do not report skipped tests as passedIgor Kudrin1-33/+33
This is similar to what we have already done to some other tests. See D102643, D102710, D102754. Differential Revision: https://reviews.llvm.org/D116108
2021-12-22[unittest][DebugInfo/DWARF] Check that dwarfgen::Generator is createdIgor Kudrin1-9/+13
If Generator::create() returns an error, tests should fail gracefully and report the cause, for example: [ RUN ] DebugLineBasicFixture.ParserSkipsCorrectly .../llvm/unittests/DebugInfo/DWARF/DWARFDebugLineTest.cpp:47: Failure Value of: llvm::detail::TakeExpected(ExpectedGenerator) Expected: succeeded Actual: failed (no asm backend for target nvptx64-nvidia-cuda) Differential Revision: https://reviews.llvm.org/D116106
2021-12-14DebugInfo: Migrate callers from getAsCString to dwarf::toStringDavid Blaikie1-2/+2
This makes a bunch of these call sites independent of a follow-up change I'm making to have getAsCString return Expected<const char*> for more descriptive error messages so that the failures there can be communicated up to DWARFVerifier (or other callers who want to provide more verbose diagnostics) so DWARFVerifier doesn't have to re-implement the string lookup logic and error checking.
2021-10-18[AIX] Disable tests failing due to lack of 64-bit XCOFF object file supportJake Egan1-0/+155
The following tests are failing because 64-bit XCOFF object files are not currently supported on AIX. This patch disables these tests on AIX for now. Reviewed By: shchenz Differential Revision: https://reviews.llvm.org/D111887
2021-05-14Bump googletest to 1.10.0Benjamin Kramer1-20/+20
2020-09-18DebugInfo: Simplify line table parsing to take all the units together, ↵David Blaikie1-12/+11
rather than CUs and TUs separately
2020-07-17[llvm][NFC] Add missing 'override's in unittests/Logan Smith1-5/+5
2020-07-03[DebugInfo] Use Cursor to detect errors in debug line prologue parserJames Henderson1-0/+124
Previously, the debug line parser would keep attempting to read data even if it had run out of data to read. This meant errors in parsing would often end up being reported as something else, such as an unknown version or malformed directory/filename table. This patch fixes the issues by using the Cursor API to capture errors. Reviewed by: labath Differential Revision: https://reviews.llvm.org/D83043
2020-07-02[DebugInfo] Fix LineTest byteswap for cross-targeting buildsDavid Tenty1-19/+4
Summary: The byte swap fix for big endian hosts in 9782c922cb21 (for D81570) swaps based on the host endianess, but for cross-targeting builds (i.e. big endian host targeting little endian) the host-endianess won't necessarily match the generated DWARF. This change updates the test to use symmetrical constants so the results aren't endian dependent. Reviewers: jhenderson, hubert.reinterpretcast, stevewan, ikudrin Reviewed By: ikudrin Subscribers: ikudrin, aprantl, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D82827
2020-06-23[DebugInfo][test] Attempt to fix big endian build botsJames Henderson1-0/+15
Commit 9782c922c broke them since it prints raw bytes, whose order will be different dependent on the endianness of the host.
2020-06-23[DebugInfo] Print line table extended opcode bytes if parsing failsJames Henderson1-21/+28
Previously, if there was an error whilst parsing the operands of an extended opcode, the operands would be treated as zero and printed. This could potentially be slightly confusing. This patch changes the behaviour to print the raw bytes instead. Reviewed by: ikudrin Differential Revision: https://reviews.llvm.org/D81570
2020-06-15[DebugInfo] Report errors for truncated debug line standard opcodeJames Henderson1-27/+109
Standard opcodes usually have ULEB128 arguments, so it is generally not possible to recover from such errors. This patch causes the parser to stop parsing the table in such situations. Also don't emit the operands or add data to the table if there is an error reading these opcodes. Reviewed by: JDevlieghere Differential Revision: https://reviews.llvm.org/D81470
2020-06-11[llvm/DWARFDebugLine] Remove spurious full stop from warning messagesPavel Labath1-1/+1
Other warnings messages don't have a trailing full stop.
2020-06-11[llvm/DWARFDebugLine] Fix a typo in one warning messagePavel Labath1-1/+1
2020-06-10[DWARFDebugLine] Use truncating data extractors for prologue parsingPavel Labath1-31/+24
Summary: This makes the code easier to reason about, as it will behave the same way regardless of whether there is any more data coming after the presumed end of the prologue. Reviewers: jhenderson, dblaikie, probinson, ikudrin Subscribers: hiraditya, MaskRay, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D77557
2020-06-09[DebugInfo] Fix printing of unrecognised standard opcodesJames Henderson1-33/+36
The verbose printing of unrecognised standard opcodes was broken in multiple ways (additional blank lines, a closing parenthesis without opening parenthesis and so on). This patch fixes it, and makes the output more consistent with other opcodes.
2020-06-09[DebugInfo] Improve new line printing in debug line verbose outputJames Henderson1-33/+118
The new line printing for debug line verbose output was inconsistent. For new rows in the matrix, a blank line followed, whilst the DW_LNS_copy opcode actually resulted in two blank lines. There was also potential inconsistency in the blank lines at the end of the table. This patch mostly resolves these issues - no blank lines appear in the output except for a single line after the prologue and at table end to separate it from any subsquent table, plus some instances after error messages. Also add a unit test for verbose output to test the fine details of new line placement and other aspects of verbose output. Reviewed by: dblaikie Differential Revision: https://reviews.llvm.org/D81102
2020-06-09[DebugInfo] Print non-verbose output at some point as verbose outputJames Henderson1-3/+7
Verbose and non-verbose parsing of .debug_line produced their output at different points in the program. The most obvious impact of this was that error messages were produced at different times, but it also potentially reduced what clients could do by customising the stream or warning/error handlers. This change makes the two variants consistent by printing non-verbose output inline, the same as verbose output. Testing of the error messages has been modified to check the messages always appear in the same location to illustrate the behaviour. Reviewed by: JDevlieghere, dblaikie, MaskRay, labath Differential Revision: https://reviews.llvm.org/D80989
2020-06-09[DebugInfo] Check for errors when reading data for extended opcodeJames Henderson1-0/+111
Previously, if an extended opcode was truncated, it would manifest as an "unexpected line op length error" which wasn't quite accurate. This change checks for errors any time data is read whilst parsing an extended opcode, and reports any errors detected. Reviewed by: MaskRay, labath, aprantl Differential Revision: https://reviews.llvm.org/D80797
2020-06-02[Support] Make DataExtractor error messages more clearPavel Labath1-2/+3
Summary: This is a result of the discussion at D78113. Previously we would be only giving the current offset at which the error was detected. However, this was phrased somewhat ambiguously (as it could also mean that end of data was at that offset). The new error message includes the current offset as well as the extent of the data being read. I've changed a couple of file-level static functions into private member functions in order to avoid passing a bunch of new arguments everywhere. Reviewers: dblaikie, jhenderson Subscribers: hiraditya, MaskRay, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D78558
2020-04-21[DWARFDebugLine] Check for errors when parsing v2 file/dir listsPavel Labath1-16/+21
Summary: Without this we could silently accept an invalid prologue because the default DataExtractor behavior is to return an empty string when reaching the end of file. And empty string is also used to terminate these lists. This makes the parsing code slightly more complicated, but this complexity will go away once the parser starts working with truncating data extractors. The reason I am doing it this way is because without this, the truncation would regress the quality of error messages (right now, we produce bad error messages only near EOF, but truncation would make everything behave as if it was near EOF). Reviewers: dblaikie, probinson, jhenderson Subscribers: hiraditya, MaskRay, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D77555
2020-03-20Cleanup the plumbing for DILineInfoSpecifier. [NFC - Try 2]Sterling Augustine1-1/+6
2020-03-19Revert "Cleanup the plumbing for DILineInfoSpecifier. [NFC]"Sterling Augustine1-6/+1
This broke lldb. Will fix and resubmit. This reverts commit 98ff6eb679cd5a2556d990d3d629e6c03c1da6a0.
2020-03-19Cleanup the plumbing for DILineInfoSpecifier. [NFC]Sterling Augustine1-1/+6
Summary: 1. FileLineInfoSpecifier::Default isn't the default for anything. Rename to RawValue, which accurately reflects its role. 2. Most functions that take a part of a FileLineInfoSpecifier end up constructing a full one later or plumb two values through. Make them all just take a complete FileLineInfoSpecifier. 3. Printing basenames only was handled differently from all other variants, make it parallel to all the other variants. Reviewers: jhenderson Subscribers: hiraditya, MaskRay, rupprecht, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D76394
2020-03-09[DebugInfo] Add check for .debug_line minimum_instruction_length of 0James Henderson1-0/+35
If the minimum_instruction_length of a debug line program is 0, no address advancing via special opcodes, DW_LNS_const_add_pc, and DW_LNS_advance_pc can occur, since the minimum_instruction_length is used in a multiplication. This patch adds a warning reporting when this issue occurs. Reviewed by: probinson Differential Revision: https://reviews.llvm.org/D75189
2020-03-09[DebugInfo] Prevent crash when .debug_line line_range is zeroJames Henderson1-0/+40
The line_range value of a debug line program header is used in divisions related to special opcodes and DW_LNS_const_add_pc opcodes. As such, a value of 0 cannot be used. This change introduces a new warning, if such a situation is identified, and does not perform the relevant calculations. Reviewed by: probinson, aprantl Differential Revision: https://reviews.llvm.org/D43470
2020-03-09[DebugInfo] Report unsupported maximum_operations_per_instruction valuesJames Henderson1-0/+207
This patch adds a check which reports an unsupported value of the maximum_operations_per_instruction field in a debug line table header. This is reported once per line table, at most, and only if the tablet would otherwise need to use it (i.e. never for tables with version 3 or less, or for tables which don't use DW_LNS_const_add_pc or special opcodes). Unsupported values are currently any apart from 1. Reviewed by: probinson, MaskRay Differential Revision: https://reviews.llvm.org/D74819
2020-03-02[DWARFDebugLine] Use new DWARFDataExtractor::getInitialLengthPavel Labath1-20/+25
Summary: The error messages change somewhat, but I believe the overall informational value remains unchanged. Reviewers: jhenderson, dblaikie, ikudrin Subscribers: hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D75116
2020-02-24Use new FailedWithMessage matcher in DWARFDebugLineTest.cppPavel Labath1-118/+110
Summary: This should produce slightly better error messages in case of failures. Only slightly, because this code was pretty careful about that to begin with -- I've seen code which does much worse. Reviewers: jhenderson, dblaikie Subscribers: llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D74899
2020-02-14[test][DebugInfo] Fix signed/unsigned comparison problem in testJames Henderson1-2/+2
This caused build bot failures: http://lab.llvm.org:8011/builders/ppc64le-lld-multistage-test/builds/8568/
2020-02-14[DebugInfo] Error if unsupported address size detected in line tableJames Henderson1-0/+94
Prior to this patch, if a DW_LNE_set_address opcode was parsed with an address size (i.e. with a length after the opcode) of anything other 1, 2, 4, or 8, an llvm_unreachable would be hit, as the data extractor does not support other values. This patch introduces a new error check that verifies the address size is one of the supported sizes, in common with other places within the DWARF parsing. This patch also fixes calculation of a generated line table's size in unit tests. One of the tests in this patch highlighted a bug introduced in 1271cde4745, when non-byte operands were used as arguments for extended or standard opcodes. Reviewed by: dblaikie Differential Revision: https://reviews.llvm.org/D73962
2020-02-12[DebugInfo] Add checks for v2 directory and file name table terminatorsJames Henderson1-17/+23
The DWARFv2-4 specification for the line table header states that the include directories and file name tables both end with a single null byte. Prior to this change, the parser did not detect if this byte was missing, because it also stopped reading the tables once it reached the prologue end, as claimed by the header_length field. This change adds a check that the terminator has been seen at the end of each table. Reviewed by: dblaikie, MaskRay Differential Revision: https://reviews.llvm.org/D74413
2020-02-12[DebugInfo] Print version in error message in decimalJames Henderson1-21/+18
Also remove some test duplication and add a test case that shows the maximum version is rejected (this also shows that the value in the error message is actually in decimal, and not just missing an 0x prefix). Reviewed by: dblaikie Differential Revision: https://reviews.llvm.org/D74403
2020-02-11Update test for windows.Sterling Augustine1-2/+2
2020-02-11Allow retrieving source files relative to the compilation directory.Sterling Augustine1-0/+47
Summary: Dwarf stores source-file names the three parts: <compilation_directory><include_directory><filename> Prior to this change, the code only allowed retrieving either all three as the absolute path, or just the filename. But many compile-command lines--especially those in hermetic build systems don't specify an absolute path, nor just the filename, but rather the path relative to the compilation directory. This features allows retrieving them in that style. Add tests for path printing styles. Modify createBasicPrologue to handle include directories. Subscribers: aprantl, hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D73383
2020-02-10[DebugInfo] Support file-level include directories when generating DWARFv5 ↵Sterling Augustine1-1/+2
LineTable prologues. Differential Revision: https://reviews.llvm.org/D74249
2020-02-10[DebugInfo] Reject line tables of version > 5James Henderson1-0/+15
If a debug line section with version of greater than 5 is encountered, prior to this change the parser would accept it and treat it as version 5. This might work to some extent, but then it might not at all, as it really depends on the format of the unspecified future version, which will be different (otherwise there would be no point in changing the version number). Any information we could provide has a good chance of being invalid, so we should just refuse to parse such tables. Reviewed by: dblaikie, MaskRay Differential Revision: https://reviews.llvm.org/D74204
2020-02-10[NFC] Fix line endingsJames Henderson1-904/+904
2020-02-03[DebugInfo][test] Adjust line table unit length to account for contentsJames Henderson1-3/+2
Previously, if a debug line Prologue was created via createBasicPrologue, its TotalLength field did not account for any contents in the table itself. This change fixes this issue. Reviewed by: probinson Differential Revision: https://reviews.llvm.org/D73772
2020-01-30[DebugInfo] Fix DebugLine::Prologue::getLengthJames Henderson1-0/+23
The function a) returned 32-bits when in DWARF64, the PrologueLength field is 64-bits in size, and b) didn't work for DWARF version 5. Also deleted some related dead code. With this deletion, getLength is itself dead, but another change is about to make use of it. Reviewed by: probinson Differential Revision: https://reviews.llvm.org/D73626
2020-01-29[DebugInfo] Make most debug line prologue errors non-fatal to parsingJames Henderson1-12/+44
Many of the debug line prologue errors are not inherently fatal. In most cases, we can make reasonable assumptions and carry on. This patch does exactly that. In the case of length problems, the approach of "assume stated length is correct" is taken which means the offset might need adjusting. This is a relanding of b94191fe, fixing an LLD test and the LLDB build. Reviewed by: dblaikie, labath Differential Revision: https://reviews.llvm.org/D72158
2020-01-28Revert "[DebugInfo] Make most debug line prologue errors non-fatal to parsing"James Henderson1-44/+12
This reverts commit b94191fecdbadc18b342a27df1109754edcb8c4b. The change broke both an LLD test and the LLDB build.
2020-01-28[DebugInfo] Make most debug line prologue errors non-fatal to parsingJames Henderson1-12/+44
Many of the debug line prologue errors are not inherently fatal. In most cases, we can make reasonable assumptions and carry on. This patch does exactly that. In the case of length problems, the approach of "the claimed length is correct" is taken to be consistent with other instances such as the SectionParser, which ignores the read length. Reviewed by: dblaikie Differential Revision: https://reviews.llvm.org/D72158
generated by cgit v1.1 at 2025-08-02 23:48:00 +0000