The fix form sizes use to have two arrays: one for 4 byte addresses and in for 8 byte addresses. The table had an issue where DW_FORM_flag_present wasn't being represented as a fixed size form because its actual size _is_ zero and zero was used to indicate the form isn't fixed in size. Any code that needed to quickly access the DWARF had to get a FixedFormSizes instance using the address byte size.
This fix cleans things up by adding a DWARFFormValue::GetFixedSize() both as a static method and as a member function on DWARFFormValue. It correctly can indicate if a form size is zero. This cleanup is a precursor to a follow up patch where I hope to speed up DWARF parsing.
I verified performance doesn't regress by loading hundreds of DWARF files and setting a breakpoint by file and line and by name in files that do not have DWARF indexes. Performance remained consistent between the two approaches.
Differential Revision: https://reviews.llvm.org/D62416
llvm-svn: 361675
Summary:
Previous patch (r360409) introduced the "symbol file unwind plan"
concept, but that plan wasn't used for unwinding yet. With this patch,
we start to consider the new plan as a possible strategy for both
synchronous and asynchronous unwinding. I also add a test that asserts
that unwinding via breakpad STACK CFI info works end-to-end.
Reviewers: jasonmolenda, clayborg
Subscribers: lldb-commits, amccarth, markmentovai
Differential Revision: https://reviews.llvm.org/D61853
llvm-svn: 361618
Summary:
This patch implements the main feature of type units. When completing a
type, if we encounter a DW_AT_signature attribute, we use it's value to
lookup the complete definition of the type in the relevant type unit.
To enable this lookup, we build up a map of all type units in a symbol
file when parsing the units. Then we consult this map when resolving the
DW_AT_signature attribute.
I include add a couple of tests which exercise the type lookup feature,
including one that ensure we do something reasonable in case we fail to
lookup the type.
A lot of the ideas in this patch have been taken from D32167 and D61505.
Reviewers: clayborg, JDevlieghere, aprantl, alexshap
Subscribers: mgrang, lldb-commits
Differential Revision: https://reviews.llvm.org/D62246
llvm-svn: 361603
Summary:
SymbolFileDWARF used to load debug sections in a thread-safe manner.
When we moved to DWARFContext, we dropped the thread-safe part, because
we thought it was not necessary.
It turns out this was only mostly correct.
The "mostly" part is there because this is a problem only if we use the
manual index, as that is the only source of intra-module paralelism.
Also, this only seems to occur for extremely simple files (like the ones
I've been creating for tests lately), where we've managed to start
indexing before loading the debug_str section. Then, two threads start
to load the section simultaneously and produce wrong results.
On more complex files, something seems to be loading the debug_str section
before we start indexing, as I haven't been able to reproduce this
there, but I have not investigated what it is.
I've tried to come up with a test for this, but I haven't been able to
reproduce the problem reliably. Still, while doing so, I created a way
to generate many compile units on demand. Given that most of our tests
work with only one or two compile units, it seems like this could be
useful anyway.
Reviewers: aprantl, JDevlieghere, clayborg
Subscribers: arphaman, lldb-commits
Differential Revision: https://reviews.llvm.org/D62316
llvm-svn: 361602
I touched the Broadcaster class earlier today (r361544) and noticed a
few things that could be improved. This patch includes variety of small
fixes: use early returns, use LLDB_LOG macro, use doxygen comments and
finally format the class.
llvm-svn: 361597
Summary:
Fixing this error on windows build bot:
```
E:\build_slave\lldb-x64-windows-ninja\llvm\tools\lldb\source\Host\common\HostNativeThreadBase.cpp(21): error C2440: 'initializing': cannot convert from 'nullptr' to 'lldb::thread_result_t'
E:\build_slave\lldb-x64-windows-ninja\llvm\tools\lldb\source\Host\common\HostNativeThreadBase.cpp(21): note: A native nullptr can only be converted to bool or, using reinterpret_cast, to an integral type
E:\build_slave\lldb-x64-windows-ninja\llvm\tools\lldb\source\Host\common\HostNativeThreadBase.cpp(21): error C2439: 'lldb_private::HostNativeThreadBase::m_result': member could not be initialized
E:\build_slave\lldb-x64-windows-ninja\llvm\tools\lldb\include\lldb/Host/HostNativeThreadBase.h(48): note: see declaration of 'lldb_private::HostNativeThreadBase::m_result'
E:\build_slave\lldb-x64-windows-ninja\llvm\tools\lldb\source\Host\common\HostNativeThreadBase.cpp(24): error C2440: 'initializing': cannot convert from 'nullptr' to 'lldb::thread_result_t'
E:\build_slave\lldb-x64-windows-ninja\llvm\tools\lldb\source\Host\common\HostNativeThreadBase.cpp(24): note: A native nullptr can only be converted to bool or, using reinterpret_cast, to an integral type
E:\build_slave\lldb-x64-windows-ninja\llvm\tools\lldb\source\Host\common\HostNativeThreadBase.cpp(24): error C2439: 'lldb_private::HostNativeThreadBase::m_result': member could not be initialized
E:\build_slave\lldb-x64-windows-ninja\llvm\tools\lldb\include\lldb/Host/HostNativeThreadBase.h(48): note: see declaration of 'lldb_private::HostNativeThreadBase::m_result'
E:\build_slave\lldb-x64-windows-ninja\llvm\tools\lldb\source\Host\common\HostNativeThreadBase.cpp(40): error C2440: '=': cannot convert from 'nullptr' to 'lldb::thread_result_t'
E:\build_slave\lldb-x64-windows-ninja\llvm\tools\lldb\source\Host\common\HostNativeThreadBase.cpp(40): note: A native nullptr can only be converted to bool or, using reinterpret_cast, to an integral type
E:\build_slave\lldb-x64-windows-ninja\llvm\tools\lldb\source\Host\common\HostNativeThreadBase.cpp(50): error C2440: '=': cannot convert from 'nullptr' to 'lldb::thread_result_t'
E:\build_slave\lldb-x64-windows-ninja\llvm\tools\lldb\source\Host\common\HostNativeThreadBase.cpp(50): note: A native nullptr can only be converted to bool or, using reinterpret_cast, to an integral type
```
see http://lab.llvm.org:8011/builders/lldb-x64-windows-ninja/builds/5050/steps/build/logs/stdio
Reviewers: stella.stamenova, JDevlieghere
Reviewed By: JDevlieghere
Subscribers: lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D62337
llvm-svn: 361565
The copy constructor of RegularExpression doesn't initialize m_comp_err. This causes an use-of-initialized-value error when a RegularExpression is copied: the copy constructor calls Compile, which calls Free to free the existing regex if needed, which in turn reads m_comp_err to check if there's any regex to be freed.
This change calls the default constructor from the other constructors to make sure members are always initialized with sensible values. This also avoids duplicating init logic, like the RegularExpression(llvm:StringRef) constructor does, which is error prone.
Differential Revision: https://reviews.llvm.org/D62334
llvm-svn: 361546
Summary:
On Windows `lldb::thread_result_t` resolves to `typedef unsigned thread_result_t;` and on other platforms it resolves to `typedef void *thread_result_t;`.
Therefore one cannot use `nullptr` when returning from a function that returns `thread_result_t`.
I've made this change because a windows build bot fails with these errors:
```
E:\build_slave\lldb-x64-windows-ninja\llvm\tools\lldb\source\Core\Communication.cpp(362): error C2440: 'return': cannot convert from 'nullptr' to 'lldb::thread_result_t'
E:\build_slave\lldb-x64-windows-ninja\llvm\tools\lldb\source\Core\Communication.cpp(362): note: A native nullptr can only be converted to bool or, using reinterpret_cast, to an integral type
```
and
```
E:\build_slave\lldb-x64-windows-ninja\llvm\tools\lldb\source\Core\Debugger.cpp(1619): error C2440: 'return': cannot convert from 'nullptr' to 'lldb::thread_result_t'
E:\build_slave\lldb-x64-windows-ninja\llvm\tools\lldb\source\Core\Debugger.cpp(1619): note: A native nullptr can only be converted to bool or, using reinterpret_cast, to an integral type
E:\build_slave\lldb-x64-windows-ninja\llvm\tools\lldb\source\Core\Debugger.cpp(1664): error C2440: 'return': cannot convert from 'nullptr' to 'lldb::thread_result_t'
E:\build_slave\lldb-x64-windows-ninja\llvm\tools\lldb\source\Core\Debugger.cpp(1664): note: A native nullptr can only be converted to bool or, using reinterpret_cast, to an integral type
```
This is the failing build: http://lab.llvm.org:8011/builders/lldb-x64-windows-ninja/builds/5035/steps/build/logs/stdio
Reviewers: JDevlieghere, teemperor, jankratochvil, labath, clayborg, RKSimon, courbet, jhenderson
Reviewed By: labath, clayborg
Subscribers: labath, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D62305
llvm-svn: 361503
Summary:
NFC = [[ https://llvm.org/docs/Lexicon.html#nfc | Non functional change ]]
This commit is the result of modernizing the LLDB codebase by using
`nullptr` instread of `0` or `NULL`. See
https://clang.llvm.org/extra/clang-tidy/checks/modernize-use-nullptr.html
for more information.
This is the command I ran and I to fix and format the code base:
```
run-clang-tidy.py \
-header-filter='.*' \
-checks='-*,modernize-use-nullptr' \
-fix ~/dev/llvm-project/lldb/.* \
-format \
-style LLVM \
-p ~/llvm-builds/debug-ninja-gcc
```
NOTE: There were also changes to `llvm/utils/unittest` but I did not
include them because I felt that maybe this library shall be updated in
isolation somehow.
NOTE: I know this is a rather large commit but it is a nobrainer in most
parts.
Reviewers: martong, espindola, shafik, #lldb, JDevlieghere
Reviewed By: JDevlieghere
Subscribers: arsenm, jvesely, nhaehnle, hiraditya, JDevlieghere, teemperor, rnkovacs, emaste, kubamracek, nemanjai, ki.stfu, javed.absar, arichardson, kbarton, jrtc27, MaskRay, atanasyan, dexonsmith, arphaman, jfb, jsji, jdoerfert, lldb-commits, llvm-commits
Tags: #lldb, #llvm
Differential Revision: https://reviews.llvm.org/D61847
llvm-svn: 361484
Summary:
Type units don't describe any code, so they should never be the result
of any address lookup queries.
Previously, we would compute the address ranges for the type units for
via the line tables they reference because the type units looked a lot
like line-tables-only compile units. However, this is not correct, as
the line tables are only referenced from type units so that other
declarations can use the file names contained in them.
In this patch I make the BuildAddressRangeTable function virtual, and
implement it only for compile units.
Testing this was a bit tricky, because the behavior depends on the order
in which we add things to the address range map. This rarely caused a
problem with DWARF v4 type units, as they are always added after all
CUs. It happened more frequently with DWARF v5, as there clang emits the
type units first. However, this is still not something that it is
required to do, so for testing I've created an assembly file where I've
deliberately sandwiched a compile unit between two type units, which
should isolate us from both changes in how the compiler emits the units
and changes in the order we process them.
Reviewers: clayborg, aprantl, JDevlieghere
Subscribers: jdoerfert, lldb-commits
Differential Revision: https://reviews.llvm.org/D62178
llvm-svn: 361465
In D61502#1503247 @clayborg suggested that DWARFUnit *+dw_offset_t can be now
replaced by DWARFDIE.
It is moved from DWARFDebugInfoEntry to DWARFDIE as noted by @clayborg.
I have also removed return type as (1) it was wrong in one case and (2) no
existing caller used the return type. I also refactored the deep nesting noted
by @JDevlieghere.
Differential Revision: https://reviews.llvm.org/D62211
llvm-svn: 361463
Replaces the remaining C-style casts with explicit casts in Utility. The
motivation is that they are (1) easier to spot and (2) don't have
multiple meanings.
llvm-svn: 361458
This patch updates assembler attributes for AArch64 targets so we can disassemble newer instructions supported in ISA version 8.5 and SVE extensions.
Differential Revision: https://reviews.llvm.org/D62235
llvm-svn: 361451
The Windows Code Generation model cannot generation code with the PIC relocation
model - all code is implicitly position independent due to the DLL load slide
that occurs if it is not loaded at the preferred base address. Invert the
condition and inline the single use of the variable. This should also aid the
WASM target. This significantly improves the state of the (swift) repl on
Windows (and should aid in expression evaluation on Windows).
llvm-svn: 361443
Summary:
From what I understand, it's possible for multiple threads to request
a specific language runtime (e.g. CPPLanguageRuntime). This leads to a data
race.
Reviewers: jingham, JDevlieghere, compnerd, clayborg
Differential Revision: https://reviews.llvm.org/D62169
llvm-svn: 361442
The patch in r359029 missed a few accessors and mutators. This patch
also changes the lock to a recursive one as OptionValueFileSpecList::Clear()
can be invoked from some of the other methods.
llvm-svn: 361440
Rewrite the GetHistoryFilePath implementation without relying on
FileSpec in the spirit of our discussion in D61994.
It changes LLDBs behavior in two ways:
1. We now only use the -widehistory suffix when LLDB is built with wchar
support, instead of as the fallback from when the ~/.lldb directory
isn't writable.
2. When the ~/.lldb directory isn't writable, we don't write any history
files at all. Previously we would write them to the user's home
directory (with the incorrect wide suffix), polluting ~ with a
different file for every IO handler.
Differential revision: https://reviews.llvm.org/D62216
llvm-svn: 361412
Summary:
Log the AST of the TU associated with LLDB's `expr` command, once a declaration
is completed
Reviewers: shafik
Subscribers: rnkovacs, dkrupp, Szelethus, gamesh411, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D62061
llvm-svn: 361362
Summary:
This patch introduces the DWARFTypeUnit class, and teaches lldb to parse
type units out of both the debug_types section (DWARF v4), and from the
regular debug_info section (DWARF v5).
The most important piece of functionality - resolving DW_AT_signatures
to connect type forward declarations to their definitions - is not
implemented here, but even without that, a lot of functionality becomes
available. I've added tests for the commands that start to work after
this patch.
The changes in this patch were greatly inspired by D61505, which in turn took
over changes from D32167.
Reviewers: JDevlieghere, clayborg, aprantl
Subscribers: mgorny, jankratochvil, lldb-commits
Differential Revision: https://reviews.llvm.org/D62008
llvm-svn: 361360
When I moved the resolve code from FileSpec to the FileSystem class, I
introduced a regression. If you compare the two implementations, you'll
notice that if the path doesn't exist, we should only reverse the
effects of makeAbsolute, not the effects of tilde expansion.
As a result, the logic to create the ~/.lldb directory broke, because we
would resolve the path before creating it. Because the directory didn't
exist yet, we'd call create_directories on the unresolved path, which
failed.
Differential revision: https://reviews.llvm.org/D62219
llvm-svn: 361321
In D61502#1503247 @clayborg suggested that SymbolFileDWARF *dwarf2Data is
really redundant in all the calls with also having DWARFUnit *cu. So remove it.
One `SymbolFileDWARF *` nullptr check
(DWARFDebugInfoEntry::GetDIENamesAndRanges) could be removed, other two nullptr
checks (DWARFDebugInfoEntry::GetName and DWARFDebugInfoEntry::AppendTypeName)
need to stay in place (now for `DWARFUnit *`).
Differential Revision: https://reviews.llvm.org/D62011
llvm-svn: 361277
Summary:
This patch introduces the DWARFUnitHeader class. Its purpose (and its
structure, to the extent it was possible to make it) is the same as its
LLVM counterpart -- to extract the unit header information before we
actually construct the unit, so that we know which kind of units to
construct. This is needed because as of DWARF5, type units live in the
.debug_info section, which means it's not possible to statically
determine the type of units in a given section.
Reviewers: aprantl, clayborg, JDevlieghere
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D62073
llvm-svn: 361224
This moves the sections from SymbolFileDWARF to DWARFContext, where it
was trivial to do so. A couple of sections are still left in
SymbolFileDWARF. These will be handled by separate patches.
llvm-svn: 361127
This reverts commit c28f81797084b8416ff5be4f9e79000a9741ca6a.
This reverts commit 7e79b64642486f510f7872174eb831df68d65b84.
Looks like there is more work to be done on this patch. I've spoken to
the author and for the time being we will revert to keep the buildbots
green.
llvm-svn: 361086
I was looking at the current implementation of SourceInitFile and there
were a few things that made this function hard to read:
* The code to find the ~/.lldbinit file is duplicated across the cwd
and non-cwd branch.
* The ./.lldbinit is once computed by resolving .lldbinit and once by
resolving ./.lldbinit.
* It wasn't clear to me what happened when you're sourcing the
.lldbinit file in the current working directory. Apparently we do
nothing when we property to control that is set to warn (makes sense)
and we don't care when the property is set to true (debatable).
* There were at least two branches where the status of the
CommandReturnObject were not set.
This patch attempts to simplify that code.
Differential revision: https://reviews.llvm.org/D61994
llvm-svn: 361080
This is a general fix for the ConnectionFileDescriptor class but my main
motivation was to make lldb-server working with IPv6.
The connect URI can use square brackets ([]) to wrap the interface part
of the URI (e.g.: <scheme>://[<interface>]:<port>). For IPv6 addresses
this is a must since its ip can include colons and it will overlap with
the port colon otherwise. The URIParser class parses the square brackets
correctly but the ConnectionFileDescriptor doesn't generate them for
IPv6 addresses making it impossible to connect to the gdb server when
using this protocol.
How to reproduce the issue:
$ lldb-server p --server --listen [::1]:8080
...
$ lldb
(lldb) platform select remote-macosx
(lldb) platform connect connect://[::1]:8080
(lldb) platform process -p <pid>
error: unable to launch a GDB server on 'computer'
The server was actually launched we were just not able to connect to it.
With this fix lldb will correctly connect. I fixed this by wrapping the
ip portion with [].
Differential Revision: https://reviews.llvm.org/D61833
Patch by António Afonso <antonio.afonso@gmail.com>
llvm-svn: 361079
Get*AtIndex() can return nullptr. This only happens in the swift
REPL support, so it's hard to test upstream.
<rdar://problem/50875178>
llvm-svn: 361078
The change that was committed for this used \\s to match spaces which does not work correctly on all platforms. Using [:space:] makes the test pass on both Linux and Windows
llvm-svn: 361064
Summary:
The previous attempt and moving section handling over to DWARFContext
(D59611) failed because it did not take into account the dwo sections
correctly. All DWARFContexts (even those in SymbolFileDWARFDwo) used the
main module for loading the sections, but in the dwo scenario some
sections should come from the dwo file.
This patch fixes that by making the DWARFContext aware of whether it a
dwo context or a regular one. A dwo context gets two sections lists, and
it knows where to look for a particular type of a section. This isn't
fully consistent with how the llvm DWARFContext behaves, because that
one leaves it up to the user to know whether it should ask for a dwo
section or not. However, for the time being, it seems useful to have a
single entity which knows how to peice together the debug info in dwo
and non-dwo scenarios. The rough roadmap for the future is:
- port over the rest of the sections to DWARFContext
- find a way to get rid of SymbolFileDWARFDwo/Dwp/DwpDwo. This will
likely involve adding the ability for the DWARFContext to spawn
dwo sub-contexts, similarly to how it's done in llvm.
- get rid of the special handling of the "dwo" contexts by making
sure everything knows whether it should ask for the .dwo version of
the section or not (similarly to how llvm's DWARFUnits do that)
To demonstrate how the DWARFContext should behave in this new world, I
port the debug_info section (which is debug_info.dwo in the dwo file)
handling to DWARFContext. The rest of the sections will come in
subsequent patches.
Reviewers: aprantl, clayborg, JDevlieghere
Subscribers: zturner, lldb-commits
Differential Revision: https://reviews.llvm.org/D62012
llvm-svn: 361000
Previously "bt all " would've failed as the regex didn't match
them.
Over the shoulder review by Jonas Devlieghere.
<rdar://problem/50824935>
llvm-svn: 360966
Greg Clayton