This cleanup is designed to make the https://reviews.llvm.org/D32167 patch smaller and easier to read.
Cleanup in this patch:
Allow DWARFUnit subclasses to hand out the data that should be used when decoding data for a DIE. The information might be in .debug_info or could be in .debug_types. There is a new virtual function on DWARFUnit that each subclass must override:
virtual const lldb_private::DWARFDataExtractor &DWARFUnit::GetData() const;
This allows DWARFCompileUnit and eventually DWARFTypeUnit to hand out different data to be used when decoding the DIE information.
Add a new pure virtual function to get the size of the DWARF unit header:
virtual uint32_t DWARFUnit::GetHeaderByteSize() const = 0;
This allows DWARFCompileUnit and eventually DWARFTypeUnit to hand out different offsets where the first DIE starts when decoding DIE information from the unit.
Added a new function to DWARFDataExtractor to get the size of an offset:
size_t DWARFDataExtractor::GetDWARFSizeOfOffset() const;
Removed dead dumping and parsing code in the DWARFDebugInfo class.
Inlined a bunch of calls in DWARFUnit for accessors that were just returning integer member variables.
Renamed DWARFUnit::Size() to DWARFUnit::GetHeaderByteSize() as it clearly states what it is doing and makes more sense.
Differential Revision: https://reviews.llvm.org/D46606
llvm-svn: 331892
Summary:
Before this patch the two paths were doing very different things
- the apple path searched the .apple_names section, which contained
mangled names, as well as basenames of all functions. It returned any
name it found.
- the non-accelerated path looked in the "full name" index we built
ourselves, which contained mangled as well as demangled names of all
functions (but no basenames). Then however, if it did not find a match
it did an extra search in the basename index, with some special
handling for anonymous namespaces.
This aligns the two paths by changing the non-accelerated path to return
the same results as in the apple-tables one. In pratice, this means we
will search in both the "basename", "method" and "fullname" indexes (in
the manual indexes these are separate indexes. This means the function
will return some slightly inappropriate results (e.g. bar::baz::foo when
one asks for a "full name" foo), but this can be handled by additional
filtering, independently indexing method. I've also stopped inserting
demangled names into the "fullname" index, as that is inconsistent with
the apple path.
Reviewers: clayborg, JDevlieghere
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D46576
llvm-svn: 331855
In an effort to make the .debug_types patch smaller, breaking out the part that reads the .debug_types from object files into a separate patch
Differential Revision: https://reviews.llvm.org/D46529
llvm-svn: 331777
This fixes a bug where
(lldb) target var g_ptr
would populate the global variables list with exactly one entry
because SymbolFileDWARF::ParseVariables() was invoked with a list of
DIEs pre-filtered by name, such that a subsequent call to
(lldb) fr var --show-globals
would only list that one variable, because CompileUnit::m_variables
was already initialized, fooling CompileUnit::GetVariableList().
CompileUnit::GetVariableList() grabs the *complete* list of variables
via (SymbolFileDWARF, ...)::ParseVariablesForContext and that still
calls CompileUnit::SetVariableList(variables) which acts as the
caching mechanism.
Differential Revision: https://reviews.llvm.org/D46220
llvm-svn: 331230
This is intended as a clean up after the big clang-format commit
(r280751), which unfortunately resulted in many of the comment
paragraphs in LLDB being very hard to read.
FYI, the script I used was:
import textwrap
import commands
import os
import sys
import re
tmp = "%s.tmp"%sys.argv[1]
out = open(tmp, "w+")
with open(sys.argv[1], "r") as f:
header = ""
text = ""
comment = re.compile(r'^( *//) ([^ ].*)$')
special = re.compile(r'^((([A-Z]+[: ])|([0-9]+ )).*)|(.*;)$')
for line in f:
match = comment.match(line)
if match and not special.match(match.group(2)):
# skip intentionally short comments.
if not text and len(match.group(2)) < 40:
out.write(line)
continue
if text:
text += " " + match.group(2)
else:
header = match.group(1)
text = match.group(2)
continue
if text:
filled = textwrap.wrap(text, width=(78-len(header)),
break_long_words=False)
for l in filled:
out.write(header+" "+l+'\n')
text = ""
out.write(line)
os.rename(tmp, sys.argv[1])
Differential Revision: https://reviews.llvm.org/D46144
llvm-svn: 331197
Code commonly checks if the parent DIE is DW_TAG_compile_unit.
But DW_TAG_partial_unit also acts as DW_TAG_compile_unit for DWZ
as DWZ is using DW_TAG_imported_unit only at the top unit level.
Differential revision: https://reviews.llvm.org/D40469
llvm-svn: 331194
Always normalizing lldb_private::FileSpec paths will help us get a consistent results from comparisons when setting breakpoints and when looking for source files. This also removes a lot of complexity from the comparison routines. Modified the DWARF line table parser to use the normalized compile unit directory if needed.
Differential Revision: https://reviews.llvm.org/D45977
llvm-svn: 331049
This patch by Greg Clayton drops the virtualization for DWARFPartialUnit.
The virtualization of DWARFUnit now matches more its LLVM counterpart.
DWZ patchset is going to be implementable without DWARFPartialUnit remapping.
https://reviews.llvm.org/D40474
This reverts commit 329423.
This reapplies commit r329305.
llvm-svn: 330084
The reverted commit changed DWARFUnit from https://reviews.llvm.org/D40466 and
https://reviews.llvm.org/D42892 that was prepared for DWARFPartialUnit and
made from it a superclass for DWARFTypeUnit. DWARFUnit's intention was:
DWARFUnit->DWARFSomeNameUnit->DWARFCompileUnit
DWARFUnit->DWARFSomeNameUnit->DWARFTypeUnit
DWARFUnit->DWARFPartialUnit
Discussed at: https://reviews.llvm.org/D45170
This reverts commit r329305.
llvm-svn: 329423
Many things that were in DWARFCompileUnit actually need to be in DWARFUnit. This patch moves all DWARFUnit specific things over into DWARFUnit and fixes the layering. This is in preparation for adding DWARFTypeUnit for the .debug_types patch.
Differential Revision: https://reviews.llvm.org/D45170
llvm-svn: 329305
Now the codebase can use the DWARFUnit superclass. It will make it later
seamlessly work also with DWARFPartialUnit for DWZ.
This patch is only a search-and-replace easily undone, nothing interesting
in it.
Differential revision: https://reviews.llvm.org/D42892
llvm-svn: 327810
Summary:
The llvm function is equivalent to this one. Where possible I tried to
replace const char* with llvm::StringRef to avoid extra strlen
computations. In most places, I was able to track the c string back to
the ConstString it was created from.
I also create a test that verifies we are able to lookup names with
unicode characters, as a bug in the llvm compiler (it accidentally used
a different hash function) meant this was not working until recently.
This also removes the unused ExportTable class.
Reviewers: aprantl, davide
Subscribers: JDevlieghere, lldb-commits
Differential Revision: https://reviews.llvm.org/D43596
llvm-svn: 325927
Summary:
LLDB doesn't use this code, the code has no tests, and the code does suspicious
things like hashing pointers to strings instead of the strings themselves.
Subscribers: sanjoy, mgorny, JDevlieghere
Differential Revision: https://reviews.llvm.org/D43202
llvm-svn: 324925
Initialize the default value of SymbolFileDWARF uuid with
the appropriately shifted DW_INVALID_OFFSET constant.
This change fixes the collision in the computation of DIE uid
(inside DIERef::GetUID) and incorrect CompileUnit lookup
(because of the misleading cu_offset value).
Test plan: make check-lldb
Differential revision: https://reviews.llvm.org/D42563
llvm-svn: 323832
This fixes a bug in -gmodules DWARF handling when debugging without a .dSYM bundle
that was particularly noticable when debugging LLVM itself.
Debugging without clang modules and DWO handling should be unaffected by this patch.
<rdar://problem/32436209>
llvm-svn: 321802
Summary:
These two functions were calling each other, while handling different
branches of the if(IsInMemory()). This had a reason at some point in the
past, but right now it's just confusing.
I resolve this by removing the MemoryMapSectionData function and
inlining the !IsInMemory branch into ReadSectionData. There isn't
anything mmap-related in this function anyway, as the decision whether
to mmap is handled at a higher level.
This is a preparatory step to make ObjectFileELF be able to decompress
compressed sections (I want to make sure that all calls reading section
data are routed through a single piece of code).
Reviewers: clayborg
Subscribers: emaste, JDevlieghere, lldb-commits
Differential Revision: https://reviews.llvm.org/D41169
llvm-svn: 320705
DWO/DWP should not be indexed directly.
Instead, the corresponding base file should be used.
This diff adds an assert to DWARFCompileUnit::Index
and adjusts the methods
SymbolFileDWARF::FindCompleteObjCDefinitionTypeForDIE,
SymbolFileDWARF::GetObjCMethodDIEOffsets accordingly.
Differential revision: https://reviews.llvm.org/D39825
llvm-svn: 318554
The rationale here is that ArchSpec is used throughout the codebase,
including in places which should not depend on the rest of the code in
the Core module.
This commit touches many files, but most of it is just renaming of
#include lines. In a couple of cases, I removed the #include ArchSpec
line altogether, as the file was not using it. In one or two places,
this necessitated adding other #includes like lldb-private-defines.h.
llvm-svn: 318048
Previously LLDB required the DWP file
to be located next to the executable file.
This diff uses the helper function
Symbols::LocateExecutableSymbolFile to search for
DWP files in the standard locations for debug symbols.
Test plan:
Build a toy test example:
main.cpp
clang -gsplit-dwarf -g -O0 main.cpp -o main.exe
llvm-dwp -e main.exe -o main.exe.dwp
mkdir -p debug_symbols
mv main.exe.dwp debug_symbols/main.exe.dwp
Run lldb:
lldb
settings set target.debug-file-search-paths ./debug_symbols
file ./main.exe
br set --name f
run
Check that debugging works:
setting breakpoints, printing local variables.
Differential revision: https://reviews.llvm.org/D38568
llvm-svn: 315387
FreeBSD kernel modules are actually relocatable (.o) ELF files and this
previously caused some issues for LLDB. This change addresses these when
using lldb to symbolicate FreeBSD kernel backtraces.
The major problems:
- Relocations were not being applied to the DWARF debug info despite
there being code to do this. Several issues prevented it from working:
- Relocations are computed at the same time as the symbol table, but
in the case of split debug files, symbol table parsing always
redirects to the primary object file, meaning that relocations would
never be applied in the debug file.
- There's actually no guarantee that the symbol table has been parsed
yet when trying to parse debug information.
- When actually applying relocations, it will segfault because the
object files are not mapped with MAP_PRIVATE and PROT_WRITE.
- LLDB returned invalid results when performing ordinary address-to-
symbol resolution. It turned out that the addresses specified in the
section headers were all 0, so LLDB believed all the sections had
overlapping "file addresses" and would sometimes return a symbol from
the wrong section.
Patch by Brian Koropoff
Differential Revision: https://reviews.llvm.org/D38142
llvm-svn: 314672
Summary:
This allows for the stack size to be configured, which isn't
possible with std::thread. Prevents overflowing the stack when
performing complex operations in the task pool on darwin,
where the default pthread stack size is only 512kb.
This also moves TaskPool from Utility to Host.
Reviewers: labath, tberghammer, clayborg
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D37930
llvm-svn: 313637
When LLDB loads "external" modules it looks at the
presence of DW_AT_GNU_dwo_name.
However, when the already created module
(corresponding to .dwo itself) is being processed,
it will see the presence of DW_AT_GNU_dwo_name
(which contains the name of dwo file) and
will try to call ModuleList::GetSharedModule again.
In some cases (i.e. for empty files) Clang 4.0
generates a *.dwo file which has DW_AT_GNU_dwo_name,
but no DW_AT_comp_dir. In this case the method
ModuleList::GetSharedModule will fail and
the warning will be printed. To workaround this issue,
one can notice that in this case we don't actually need
to try to load the already loaded module (corresponding to .dwo).
Test plan: make check-all
Differential revision: https://reviews.llvm.org/D37295
llvm-svn: 313083
Summary:
The DWP (DWARF package) format is used to pack multiple dwo files
generated by split-dwarf into a single ELF file to make distributing
them easier. It is part of the DWARFv5 spec and can be generated by
dwp or llvm-dwp from a set of dwo files.
Caviats:
* Only the new version of the dwp format is supported (v2 in GNU
numbering schema and v5 in the DWARF spec). The old version (v1) is
already deprecated but binutils 2.24 still generates that one.
* Combining DWP files with module debugging is not yet supported.
Subscribers: emaste, mgorny, aprantl
Differential Revision: https://reviews.llvm.org/D36062
llvm-svn: 311775
It was completly unused and broke the part of the encapsulation that
common code shouldn't depend on specific plugins or language specific
features.
llvm-svn: 311000
Current LLDB (that is without DWZ support) crashes accessing Fedora debug info:
READ of size 8 at 0x60200000ffc8 thread T0
#0 in DWARFDebugInfoEntry::BuildAddressRangeTable(SymbolFileDWARF*, DWARFCompileUnit const*, DWARFDebugAranges*) const tools/lldb/source/Plugins/SymbolFile/DWARF/DWARFDebugInfoEntry.cpp:1336
Greg Clayton: We will need a warning to be emitted in
SymbolFileDWARF::CalculateAbilities() stating we won't parse the DWARF due to
"unsupported DW_FORM value of 0x1f20".
Patch has been mostly written by Greg Clayton.
Differential revision: https://reviews.llvm.org/D35622
llvm-svn: 309581
Summary:
The classes have no dependencies, and they are used both by lldb and
lldb-server, so it makes sense for them to live in the lowest layers.
Reviewers: zturner, jingham
Subscribers: emaste, mgorny, lldb-commits
Differential Revision: https://reviews.llvm.org/D34746
llvm-svn: 306682
The function does not persist the callback, so using a lighter-weight
asbtraction seems appropriate.
Also tweak the signatures of the lambdas to match what the TaskMap
interface expects.
llvm-svn: 304924
The Timer destructor would grab a global mutex in order to update
execution time. Add a class to define a category once, statically; the
class adds itself to an atomic singly linked list, and thus subsequent
updates only need to use an atomic rather than grab a lock and perform a
hashtable lookup.
Differential Revision: https://reviews.llvm.org/D32823
Patch by Scott Smith <scott.smith@purestorage.com>.
llvm-svn: 303058
This renames the LLDB error class to Status, as discussed
on the lldb-dev mailing list.
A change of this magnitude cannot easily be done without
find and replace, but that has potential to catch unwanted
occurrences of common strings such as "Error". Every effort
was made to find all the obvious things such as the word "Error"
appearing in a string, etc, but it's possible there are still
some lingering occurences left around. Hopefully nothing too
serious.
llvm-svn: 302872
Summary:
Many parallel tasks just want to iterate over all the possible numbers from 0 to N-1. Rather than enqueue N work items, instead just "map" the function across the requested integer space.
Reviewers: clayborg, labath, tberghammer, zturner
Reviewed By: clayborg, zturner
Subscribers: zturner, lldb-commits
Differential Revision: https://reviews.llvm.org/D32757
Patch by Scott Smith <scott.smith@purestorage.com>.
llvm-svn: 302223
Loading a shared library can require a large amount of work; rather than do that serially for each library,
this patch will allow parallelization of the symbols and debug info name indexes.
From scott.smith@purestorage.comhttps://reviews.llvm.org/D32598
llvm-svn: 301609
LLDB uses clang::DeclContexts for lookups, and variables get put into
the DeclContext for their abstract origin. (The abstract origin is a
DWARF pointer that indicates the unique definition of inlined code.)
When the expression parser is looking for variables, it locates the
DeclContext for the current context. This needs to be done carefully,
though, e.g.:
__attribute__ ((always_inline)) void f(int a) {
{
int b = a * 2;
}
}
void g() {
f(3);
}
Here, if we're stopped in the inlined copy of f, we have to find the
DeclContext corresponding to the definition of f – its abstract
origin. Clang doesn't allow multiple functions with the same name and
arguments to exist. It also means that any variables we see must be
placed in the appropriate DeclContext.
[Bug 1]: When stopped in an inline block, the function
GetDeclContextDIEContainingDIE for that block doesn't properly
construct a DeclContext for the abstract origin for inlined
subroutines. That means we get duplicated function DeclContexts, but
function arguments only get put in the abstract origin's DeclContext,
and as a result when we try to look for them in nested contexts they
aren't found.
[Bug 2]: When stopped in an inline block, the DWARF (for space
reasons) doesn't explicitly point to the abstract origin for that
block. This means that the function GetClangDeclContextForDIE returns
a different DeclContext for each place the block is inlined. However,
any variables defined in the block have abstract origins, so they
will only get placed in the DeclContext for their abstract origin.
In this fix, I've introduced a test covering both of these issues,
and fixed them.
Bug 1 could be resolved simply by making sure we look up the abstract
origin for inlined functions when looking up their DeclContexts on
behalf of nested blocks.
For Bug 2, I've implemented an algorithm that makes the DeclContext
for a block be the containing DeclContext for the closest entity we
would find during lookup that has an abstract origin pointer. That
means that in the following situation:
{ // block 1
int a;
{ // block 2
int b;
}
}
if we looked up the DeclContext for block 2, we'd find the block
containing the abstract origin of b, and lookup would proceed
correctly because we'd see b and a. However, in the situation
{ // block 1
int a;
{ // block 2
}
}
since there isn't anything to look up in block 2, we can't determine
its abstract origin (and there is no such pointer in the DWARF for
blocks). However, we can walk up the parent chain and find a, and its
abstract origin lives in the abstract origin of block 1. So we simply
say that the DeclContext for block 2 is the same as the DeclContext
for block 1, which contains a. Lookups will return the same results.
Thanks to Jim Ingham for review and suggestions.
Differential revision: https://reviews.llvm.org/D32375
llvm-svn: 301263
about this more I realized I could make the change isolated to
whether we decide an empty accelerator table is valid or not.
<rdar://problem/30867462>
llvm-svn: 297496
HasContent. If we have a valid accelerator table which has no
content, we want to depend on that (empty) table as the authoritative
source instead of reading through all the debug info for lookups.
<rdar://problem/30867462>
llvm-svn: 297441
This was originall reverted due to some test failures in
ModuleCache and TestCompDirSymlink. These issues have all
been resolved and the code now passes all tests.
Differential Revision: https://reviews.llvm.org/D30698
llvm-svn: 297300
this reverts r297116 because it breaks the unittests and
TestCompDirSymlink. The ModuleCache unit test is trivially fixable, but
the CompDirSymlink failure is a symptom of a deeper problem: llvm's stat
functionality is not a drop-in replacement for lldb's. The former is
based on stat(2) (which does symlink resolution), while the latter is
based on lstat(2) (which does not).
This also reverts subsequent build fixes (r297128, r297120, 297117) and
r297119 (Remove FileSpec dependency on FileSystem) which builds on top
of this.
llvm-svn: 297139
This deletes LLDB's FileType enumeration and replaces all
users, and all calls to functions that check whether a file
exists etc with corresponding calls to LLVM.
Differential Revision: https://reviews.llvm.org/D30624
llvm-svn: 297116
Changes wrt. previous version:
- add #include <atomic>: fix build on windows
- add extra {} around the string literals used to initialize
llvm::StringLiteral: fix gcc build
llvm-svn: 295442
Summary:
We currently have two log channel registration mechanisms. One uses a
set of function pointers and the other one is based on the
PluginManager.
The PluginManager dependency is unfortunate, as logging
is also used in lldb-server, and the PluginManager pulls in a lot of
classes which are not used in lldb-server.
Both approach have the problem that they leave too much to do for the
user, and so the individual log channels end up reimplementing command
line argument parsing, category listing, etc.
Here, I replace the PluginManager-based approach with a one. The new API
is more declarative, so the user only needs to specify the list of list
of channels, their descriptions, etc., and all the common tasks like
enabling/disabling categories are hadled by common code. I migrate the
LogChannelDWARF (only user of the PluginManager method) to the new API.
In the follow-up commits I'll replace the other channels with something
similar.
Reviewers: clayborg, zturner, beanz
Subscribers: aprantl, lldb-commits
Differential Revision: https://reviews.llvm.org/D29895
llvm-svn: 295190
Summary:
The std::call_once implementation in libstdc++ has problems on few systems: NetBSD, OpenBSD and Linux PPC. LLVM ships with a homegrown implementation llvm::call_once to help on these platforms.
This change is required in the NetBSD LLDB port. std::call_once with libstdc++ results with crashing the debugger.
Sponsored by <The NetBSD Foundation>
Reviewers: labath, joerg, emaste, mehdi_amini, clayborg
Reviewed By: labath, clayborg
Subscribers: #lldb
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D29288
llvm-svn: 294202
This moves the following classes from Core -> Utility.
ConstString
Error
RegularExpression
Stream
StreamString
The goal here is to get lldbUtility into a state where it has
no dependendencies except on itself and LLVM, so it can be the
starting point at which to start untangling LLDB's dependencies.
These are all low level and very widely used classes, and
previously lldbUtility had dependencies up to lldbCore in order
to use these classes. So moving then down to lldbUtility makes
sense from both the short term and long term perspective in
solving this problem.
Differential Revision: https://reviews.llvm.org/D29427
llvm-svn: 293941
This diff
1. Adds a comment to ObjectFileELF.cpp about the current
approach to determining the OS.
2. Replaces the check in SymbolFileDWARF.cpp with a more robust one.
Test plan:
Built (on Linux) a test binary linked to a c++ shared library
which contains just an implementation of a function TestFunction,
the library (the binary itself) doesn't contain ELF notes
and EI_OSABI is set to System V.
Checked in lldb that now "p TestFunction()" works fine
(and doesn't work without this patch).
Differential revision: https://reviews.llvm.org/D27380
llvm-svn: 288687
Summary:
Improve detection of global vs local variables.
Currently when a global variable is optimized out or otherwise has an unknown
location (DW_AT_location is empty) it gets reported as local.
I added two new heuristics:
- if a mangled name is present, the variable is global (or static)
- if DW_AT_location is present but invalid, the variable is global (or static)
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D26908
llvm-svn: 287636
