Profiles show that `DWARFUnit::ExtractUnitDIENoDwoIfNeeded` is both high firing (tens of thousands of calls) and fast running (15 µs mean).
Timers like this are noise and load for profiling systems, and can be removed.
rdar://100326595
Differential Revision: https://reviews.llvm.org/D134920
When debugging using Fission (-gsplit-dwarf), we can sometimes have issues loading .dwo files if they are missing or if the path was relative and we were unable to locate the file. We can also skip loading due to DWO ID mismatch or if a .dwp file doesn't contain a matching .dwo file. Also .dwo files could be updated due to a recompile and if the user debugs an executable that was linked against the old .dwo file, it could fail to load the information.
This patch adds a m_dwo_error to DWARFUnit that can be get/set and will cause "frame variable" to show errors when there are .dwo/.dwp issues informing the user about the error.
Differential Revision: https://reviews.llvm.org/D134252
D131437 caused heap-use-after-free failures when testing TestCreateAfterAttach.py in asan mode, and "regular" crashes outside of asan.
This appears to be due to a mismatch in a couple places where we choose to clear the DIEs. When we clear the DIE of a skeleton unit, we unconditionally clear the DIE of the DWO unit if it exists. However, `~ScopedExtractDIEs()` only looks at the skeleton unit when deciding to clear. If we decide to clear the skeleton unit because it is now unused, we end up clearing the DWO unit that _is_ used. This change adds a guard by checking `m_cancel_scopes` to prevent clearing the DWO unit.
This is 100% reproducible by running TestCreateAfterAttach.py in asan mode, although it only seems to reproduce in our internal build, so no test case is added here. If someone has suggestions on how to write one, I can add it.
Reviewed By: labath
Differential Revision: https://reviews.llvm.org/D133790
Summary:
Many times when debugging variables might not be available even though a user can successfully set breakpoints and stops somewhere. Letting the user know will help users fix these kinds of issues and have a better debugging experience.
Examples of this include:
- enabling -gline-tables-only and being able to set file and line breakpoints and yet see no variables
- unable to open object file for DWARF in .o file debugging for darwin targets due to modification time mismatch or not being able to locate the N_OSO file.
This patch adds an new API to SBValueList:
lldb::SBError lldb::SBValueList::GetError();
object so that if you request a stack frame's variables using SBValueList SBFrame::GetVariables(...), you can get an error the describes why the variables were not available.
This patch adds the ability to get an error back when requesting variables from a lldb_private::StackFrame when calling GetVariableList.
It also now shows an error in response to "frame variable" if we have debug info and are unable to get varialbes due to an error as mentioned above:
(lldb) frame variable
error: "a.o" object from the "/tmp/libfoo.a" archive: either the .o file doesn't exist in the archive or the modification time (0x63111541) of the .o file doesn't match
Reviewers: labath JDevlieghere aadsm yinghuitan jdoerfert sscalpone
Subscribers:
Differential Revision: https://reviews.llvm.org/D133164
Many times when debugging variables might not be available even though a user can successfully set breakpoints and stops somewhere. Letting the user know will help users fix these kinds of issues and have a better debugging experience.
Examples of this include:
- enabling -gline-tables-only and being able to set file and line breakpoints and yet see no variables
- unable to open object file for DWARF in .o file debugging for darwin targets due to modification time mismatch or not being able to locate the N_OSO file.
This patch adds an new API to SBValueList:
lldb::SBError lldb::SBValueList::GetError();
object so that if you request a stack frame's variables using SBValueList SBFrame::GetVariables(...), you can get an error the describes why the variables were not available.
This patch adds the ability to get an error back when requesting variables from a lldb_private::StackFrame when calling GetVariableList.
It also now shows an error in response to "frame variable" if we have debug info and are unable to get varialbes due to an error as mentioned above:
(lldb) frame variable
error: "a.o" object from the "/tmp/libfoo.a" archive: either the .o file doesn't exist in the archive or the modification time (0x63111541) of the .o file doesn't match
Differential Revision: https://reviews.llvm.org/D133164
When fission is enabled, we were indexing the skeleton CU _and_ the .dwo CU. Issues arise when users enable compiler options that add extra data to the skeleton CU (like -fsplit-dwarf-inlining) and there can end up being types in the skeleton CU due to template parameters. We never want to index this information since the .dwo file has the real definition, and we really don't want function prototypes from this info since all parameters are removed. The index doesn't work correctly if it does index the skeleton CU as the DIE offset will assume it is from the .dwo file, so even if we do index the skeleton CU, the index entries will try and grab information from the .dwo file using the wrong DIE offset which can cause errors to be displayed or even worse, if the DIE offsets is valid in the .dwo CU, the wrong DIE will be used.
We also fix DWO ID detection to use llvm::Optional<uint64_t> to make sure we can load a .dwo file with a DWO ID of zero.
Differential Revision: https://reviews.llvm.org/D131437
Fixing potential int overflow and uninitialized variables.
These were found by Coverity static code inspection.
Differential Revision: https://reviews.llvm.org/D130795
Rather than looking up by offset - actually use the hash table to
perform faster lookup where possible. (for DWARFv4 DWP compilation units
the hash isn't in the header - it's in the root DIE, but to parse the
DIE you need the abbrev section and to get the abbrev section you need
the index - so in that case lookup by offset is required)
We have using namespace llvm::dwarf in dwarf.h header globally. Replacing that
with a using namespace within lldb_private::dwarf and moving to a
using namespace lldb_private::dwarf in .cpp files and fully qualified names
in the few header files.
Differential Revision: https://reviews.llvm.org/D120836
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
The new key/value pairs that are added to each module's stats are:
"debugInfoByteSize": The size in bytes of debug info for each module.
"debugInfoIndexTime": The time in seconds that it took to index the debug info.
"debugInfoParseTime": The time in seconds that debug info had to be parsed.
At the top level we add up all of the debug info size, parse time and index time with the following keys:
"totalDebugInfoByteSize": The size in bytes of all debug info in all modules.
"totalDebugInfoIndexTime": The time in seconds that it took to index all debug info if it was indexed for all modules.
"totalDebugInfoParseTime": The time in seconds that debug info was parsed for all modules.
Differential Revision: https://reviews.llvm.org/D112501
This has the nice side-effect that it can actually store the quadruple version numbers that Apple's tools are using nowadays.
rdar://82982162
Differential Revision: https://reviews.llvm.org/D111200
Replace misc. StringConvert uses with llvm::to_integer()
and llvm::to_float(), except for cases where further refactoring is
planned. The purpose of this change is to eliminate the StringConvert
API that is duplicate to LLVM, and less correct in behavior at the same
time.
Differential Revision: https://reviews.llvm.org/D110447
This patch considers the CU index entry
when reading the .debug_rnglists.dwo section.
Reviewed By: jankratochvil
Differential Revision: https://reviews.llvm.org/D107456
Fix D98289 so that it works even for 2nd..nth compilation unit
(.debug_rnglists).
Reviewed By: dblaikie, ikudrin
Differential Revision: https://reviews.llvm.org/D106466
This patch fixes the lookup of locations in
.debug_loclists, if they are split in a .dwp file.
Mainly, we need to consider the cu index offsets.
Reviewed By: jankratochvil
Differential Revision: https://reviews.llvm.org/D107161
This change makes sure that DwarfUnit does not load a .dwo file until
necessary. I also take advantage of DWARF 5's guarantee that the first
support file is also the primary file to make it possible to create
a compile unit without loading the .dwo file.
Testcases now require Linux as it is needed for -gsplit-dwarf.
Review By: jankratochvil, dblaikie
Differential Revision: https://reviews.llvm.org/D100299
This change makes sure that DwarfUnit does not load a .dwo file until
necessary. I also take advantage of DWARF 5's guarantee that the first
support file is also the primary file to make it possible to create
a compile unit without loading the .dwo file.
Review By: jankratochvil, dblaikie
Differential Revision: https://reviews.llvm.org/D100299
This change makes sure that DwarfUnit does not load a .dwo file until
necessary. I also take advantage of DWARF 5's guarantee that the first
support file is also the primary file to make it possible to create
a compile unit without loading the .dwo file.
Review By: jankratochvil, dblaikie
Differential Revision: https://reviews.llvm.org/D100299
My D99653 implemented a getter GetRnglist() for m_rnglist_table.
That was confusing as the getter returns DWARFDebugRnglistTable which
contains DWARFDebugRnglist as its elements.
In D98289#inline-939112 @dblaikie said:
Perhaps this could be more informative about what makes the range list
index of 0 invalid? "index 0 out of range of range list table (with
range list base 0xXXX) with offset entry count of XX (valid indexes
0-(XX-1))" Maybe that's too verbose/not worth worrying about since
this'll only be relevant to DWARF producers trying to debug their
DWARFv5, maybe no one will ever see this message in practice. Just
a thought.
Reviewed By: dblaikie
Differential Revision: https://reviews.llvm.org/D102851
DW_AT_ranges can use DW_FORM_sec_offset (instead of DW_FORM_rnglistx).
In such case DW_AT_rnglists_base does not need to be present.
DWARF-5 spec:
"If the offset_entry_count is zero, then DW_FORM_rnglistx cannot
be used to access a range list; DW_FORM_sec_offset must be used
instead. If the offset_entry_count is non-zero, then
DW_FORM_rnglistx may be used to access a range list;"
This fix is for TestTypeCompletion.py category `dwarf` using GCC with DWARF-5.
The fix just provides GetRnglist() lazy getter for `m_rnglist_table`.
The testcase is easier to review by:
diff -u lldb/test/Shell/SymbolFile/DWARF/DW_AT_low_pc-addrx.s \
lldb/test/Shell/SymbolFile/DWARF/DW_AT_range-DW_FORM_sec_offset.s
Differential Revision: https://reviews.llvm.org/D98289
If the debug info is missing the terminating null die, we would crash
when trying to access the nonexisting children/siblings. This was
discovered because the test case for D98619 accidentaly produced such
input.
Remove the "depth" variable, as the same information can be obtained
through die_index_stack.size().
Also add a test case for a one tricky case I noticed -- a unit
containing only a null unit die.
In DWARF v4 compile units go in .debug_info and type units go in
.debug_types. However, in v5 both kinds of units are in .debug_info.
Therefore we can't decide whether to use the CU or TU index just by
looking at which section we're reading from. We have to wait until we
have read the unit type from the header.
Differential Revision: https://reviews.llvm.org/D96194
In split DWARF v5 files, the DWO id is no longer in the DW_AT_GNU_dwo_id
attribute. It's in the CU header instead. This change makes lldb look in
both places.
Differential Revision: https://reviews.llvm.org/D93444
This patch introduces a LLDB_SCOPED_TIMER macro to hide the needlessly
repetitive creation of scoped timers in LLDB. It's similar to the
LLDB_LOG(F) macro.
Differential revision: https://reviews.llvm.org/D93663
LookupAddress makes no sense for DWARFTypeUnit.
Also make GetNonSkeletonUnit to preserve the called type.
Differential Revision: https://reviews.llvm.org/D89646
This is a preparation for an upcoming patch which adds support for
DWARFv5 unit index sections. The patch adds tag "_EXT_" to identifiers
which reference sections that are deprecated in the DWARFv5 standard.
See D75929 for the discussion.
Differential Revision: https://reviews.llvm.org/D77141
The old name was a bit misleading because the functions actually return
contributions to the corresponding sections.
Differential revision: https://reviews.llvm.org/D77302
The only thing needed was to account for the offset from the
debug_cu_index section when searching for the location list.
This patch also fixes a bug in the Module::ParseAllDebugSymbols
function, which meant that we would only parse the variables of the
first compile unit in the module. This function is only used from
lldb-test, so this does not fix any real issue, besides preventing me
from writing a test for this patch.
Summary:
In dwp files a constant (from the debug_cu_index section) needs to be
added to each reference into the debug_str_offsets section.
I've tried to implement this to roughly match the llvm flow: I've
changed the DWARFormValue to stop resolving the indirect string
references directly -- instead, it calls into DWARFUnit, which resolves
this for it (similar to how it already resolves indirect range and
location list references). I've also done a small refactor of the string
offset base computation code in DWARFUnit in order to make it easier to
access the debug_cu_index base offset.
Reviewers: JDevlieghere, aprantl, clayborg
Subscribers: lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D74723
Dave Lee