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
SymbolFileDWARFDwp contains m_debug_cu_index_map which was previously
initialized incorrectly: before m_debug_cu_index.parse
is called m_debug_cu_index is empty, thus
the map was not actually getting populated properly.
This diff moves this step into a private helper method
and calls it after m_debug_cu_index.parse inside SymbolFileDWARFDwp::Create.
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
Build LLDB with ENABLE_DEBUG_PRINTF set.
Run: lldb -- ./main.exe
Check that the indexes are now correct
(before this change they were empty)
Check that debugging works
(setting breakpoints, printing local variables (this was not working before))
Differential revision: http://reviews.llvm.org/D38492
llvm-svn: 314832
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
A clang change caused the inclusion of `llvm::Type` and
`lldb_private::Type` to be pulled into the global namespace due to the
`using namespace llvm;` and `using namespace lldb_private;`. Explicitly
qualify the `Type` to resolve the ambiguity. NFC
llvm-svn: 312841
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:
Clang recently started to emit base address entries into the
.debug_ranges section to reduce the number of relocations needed. Lets
make sure LLDB can read them.
llvm-svn: 309554
This reapplies https://reviews.llvm.org/D35740 with a tweak to find
the section by name rather than type. Section types don't distinguish
between regular sections and their DWO counterparts.
llvm-svn: 308905
The DWO handling code can get confused by clang modules which also use
skeleton CUs to point to the object file with the full debug
info. This patch detects whether an object is a "real" DWO or a clang
module and prevents LLDB from interpreting clang modules as DWO. This
fixes the regression in TestWithModuleDebugging.
http://llvm.org/bugs/show_bug.cgi?id=33875
Differential Revision: https://reviews.llvm.org/D35740
llvm-svn: 308850
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
Templates can end in parameter packs, like this
template <class T...> struct MyStruct
{ /*...*/ };
LLDB does not currently support these parameter packs;
it does not emit them into the template argument list
at all. This causes problems when you specialize, e.g.:
template <> struct MyStruct<int>
{ /*...*/ };
template <> struct MyStruct<int, int> : MyStruct<int>
{ /*...*/ };
LLDB generates two template specializations, each with
no template arguments, and then when they are imported
by the ASTImporter into a parser's AST context we get a
single specialization that inherits from itself,
causing Clang's record layout mechanism to smash its
stack.
This patch fixes the problem for classes and adds
tests. The tests for functions fail because Clang's
ASTImporter can't import them at the moment, so I've
xfailed that test.
Differential Revision: https://reviews.llvm.org/D33025
llvm-svn: 302833
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
Summary:
UniqueCStringMap "sorts" the entries for fast lookup, but really it only cares about uniqueness. ConstString can be compared by pointer alone, rather than with strcmp, resulting in much faster comparisons. Change the interface to take ConstString instead, and propagate use of the type to the callers where appropriate.
Reviewers: #lldb, clayborg
Reviewed By: clayborg
Subscribers: labath, jasonmolenda, lldb-commits
Differential Revision: https://reviews.llvm.org/D32316
Patch by Scott Smith <scott.smith@purestorage.com>.
llvm-svn: 301908
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
Summary:
previously we switched to llvm streams for log output, this completes
the switch for the error streams.
I also clean up the includes and remove the unused argument from
DisableAllLogChannels().
This required adding a bit of boiler plate to convert the output in the
command interpreter, but that should go away when we switch command
results to use llvm streams as well.
Reviewers: zturner, eugene
Subscribers: lldb-commits, emaste
Differential Revision: https://reviews.llvm.org/D30894
llvm-svn: 297812
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
In an effort to move the various DataBuffer / DataExtractor
classes from Core -> Utility, we have to separate the low-level
functionality from the higher level functionality. Only a
few functions required anything other than reading/writing
raw bytes, so those functions are separated out into a
more appropriate area. Specifically, Dump() and DumpHexBytes()
are moved into free functions in Core/DumpDataExtractor.cpp,
and GetGNUEHPointer is moved into a static function in the
only file that it's referenced from.
Differential Revision: https://reviews.llvm.org/D30560
llvm-svn: 296910
All references to Host and Core have been removed, so this
class can now safely be lowered into Utility.
Differential Revision: https://reviews.llvm.org/D30559
llvm-svn: 296909
This in turn triggered some fallout where other files had
been transitively picking up includes that they needed from
FileSpec.h, so I've fixed those up as well.
llvm-svn: 296855
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
With this patch, the only dependency left is from Utility
to Host. After this is broken, Utility will finally be
standalone.
Differential Revision: https://reviews.llvm.org/D29909
llvm-svn: 295088
Summary:
This converts LLDB's logging to use llvm streams instead of
lldb_private::Stream and friends. The changes are mostly
straight-forward and amount to s/lldb_private::Stream/llvm::raw_ostream.
The part worth calling out is the rewrite of the StreamCallback class.
Previously this class contained a per-thread buffer of data written. I
assume this had something to do with it trying to make sure each log
line is delivered as a single event, instead of multiple (possibly
interleaved) events. However, this is no longer relevant as the Log
class already writes things to a temporary buffer and then delivers the
message as a single "write", so I have just removed the code in
question.
Reviewers: zturner, clayborg
Subscribers: emaste, lldb-commits, mgorny
Differential Revision: https://reviews.llvm.org/D29615
llvm-svn: 294736
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
