This change will bring lldb-vscode in line with how several other llvm
tools process command line arguments and make it easier to add future
options.
Differential revision: https://reviews.llvm.org/D74798
Summary:
Around a third of our test sources have LLVM license headers. This patch removes those headers from all test
sources and also fixes any tests that depended on the length of the license header.
The reasons for this are:
* A few tests verify line numbers and will start failing if the number of lines in the LLVM license header changes. Once I landed my patch for valid SourceLocations in debug info we will probably have even more tests that verify line numbers.
* No other LLVM project is putting license headers in its test files to my knowledge.
* They make the test sources much more verbose than they have to be. Several tests have longer license headers than the actual test source.
For the record, the following tests had their line numbers changed to pass with the removal of the license header:
lldb-api :: functionalities/breakpoint/breakpoint_by_line_and_column/TestBreakpointByLineAndColumn.py
lldb-shell :: Reproducer/TestGDBRemoteRepro.test
lldb-shell :: Reproducer/TestMultipleTargets.test
lldb-shell :: Reproducer/TestReuseDirectory.test
lldb-shell :: ExecControl/StopHook/stop-hook-threads.test
lldb-shell :: ExecControl/StopHook/stop-hook.test
lldb-api :: lang/objc/exceptions/TestObjCExceptions.py
Reviewers: #lldb, espindola, JDevlieghere
Reviewed By: #lldb, JDevlieghere
Subscribers: emaste, aprantl, arphaman, JDevlieghere, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D74839
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:
Currently when printing data types we include implicit scopes such as inline namespaces or anonymous namespaces.
This leads to command output like this (for `std::set<X>` with X being in an anonymous namespace):
```
(lldb) print my_set
(std::__1::set<(anonymous namespace)::X, std::__1::less<(anonymous namespace)::X>, std::__1::allocator<(anonymous namespace)::X> >) $0 = size=0 {}
```
This patch removes all the implicit scopes when printing type names in TypeSystemClang::GetDisplayTypeName
so that our output now looks like this:
```
(lldb) print my_set
(std::set<X, std::less<X>, std::allocator<X> >) $0 = size=0 {}
```
As previously GetDisplayTypeName and GetTypeName had the same output we actually often used the
two as if they are the same method (they were in fact using the same implementation), so this patch also
fixes the places where we actually want the display type name and not the actual type name.
Note that this doesn't touch the `GetTypeName` class that for example the data formatters use, so this patch
is only changes the way we display types to the user. The full type name can also still be found when passing
'-R' to see the raw output of a variable in case someone is somehow interested in that.
Partly fixes rdar://problem/59292534
Reviewers: shafik, jingham
Reviewed By: shafik
Subscribers: christof, JDevlieghere, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D74478
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
Summary:
This patch removes the bitrotted SymbolFileDWARF(Dwo)Dwp classes, and
replaces them with dwp support implemented directly inside
SymbolFileDWARFDwo, in a manner mirroring the implementation in llvm.
This patch does:
- add support for the .debug_cu_index section to our DWARFContext
- adds a llvm::DWARFUnitIndex argument to the DWARFUnit constructors.
This argument is used to look up the offsets of the debug_info and
debug_abbrev contributions in the sections of the dwp file.
- makes sure the creation of the DebugInfo object as well as the initial
discovery of DWARFUnits is thread-safe, as we can now call this
concurrently when doing parallel indexing.
This patch does not:
- use the DWARFUnitIndex to search for other kinds of contributions
(debug_loc, debug_ranges, etc.). This means that units which reference
these sections will not work correctly. These will be handled by
follow-up patches, but even the present level of support is sufficient
to enable basic functionality.
- Make the llvm::DWARFContext thread-safe. Right now, it just avoids this
problem by ensuring everything is initialized ahead of time. However,
this is something we will run into more often as we try to use more of
llvm, and so I plan to start looking into our options here.
Reviewers: JDevlieghere, aprantl, clayborg
Subscribers: mgorny, mgrang, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D73783
SB API clients can describe the failure message in a more natural
way for their UI, this doesn't add information for them.
Differential Revision: https://reviews.llvm.org/D74585
<rdar://problem/49953304>
This reimplements commit 6b2979c12300b90a1e69791d43ee9cff14f4265e and updates
the tests to reflect the addition of the alternate symbol attribute.
Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
D73303 was failing on Fedora Linux and so it was disabled by Skip the
AssertFrameRecognizer test for Linux.
I find no easy way how to find out if it gets recognized as
`__assert_fail` or `__GI___assert_fail` as during `Process` ctor
libc.so.6 is not yet loaded by the debuggee.
DWARF symbol `__GI___assert_fail` overrides the ELF symbol `__assert_fail`.
While external debug info (=DWARF) gets disabled for testsuite (D55859)
that sure does not apply for real world usage.
Differential Revision: https://reviews.llvm.org/D74252
This reverts commit cf1046c716b33ed449aa8fc26376864917c63c25.
Reverted: https://reviews.llvm.org/D74252
It fixed testsuite but broke real world functionality where is not used:
settings set symbols.enable-external-lookup false
D73303 was failing on Fedora Linux and so it was disabled by Skip the
AssertFrameRecognizer test for Linux.
On Fedora 30 x86_64 I have:
$ readelf -Ws /lib64/libc.so.6 |grep '^Symbol\|.*assert_fail'
Symbol table '.dynsym' contains 2362 entries:
630: 0000000000030520 70 FUNC GLOBAL DEFAULT 14 __assert_fail@@GLIBC_2.2.5
Symbol table '.symtab' contains 22711 entries:
922: 000000000002275a 15 FUNC LOCAL DEFAULT 14 __assert_fail_base.cold
18044: 0000000000030520 70 FUNC LOCAL DEFAULT 14 __GI___assert_fail
20081: 00000000000303a0 370 FUNC LOCAL DEFAULT 14 __assert_fail_base
21766: 0000000000030520 70 FUNC GLOBAL DEFAULT 14 __assert_fail
The patch should never expect __GI___assert_fail:
.symtab can be present or not but that should not change that
__assert_fail always wins - it is always present from .dynsym and it can
never be overriden by __GI___assert_fail as __GI___assert_fail has only
local binding. Global binding is preferred since D63540.
External debug info symbols do not matter since D55859 (and DWARF should
never be embedded in system libc.so.6).
Differential Revision: https://reviews.llvm.org/D74252
This patch skips the AssertFrameRecognizer test for Linux since it appears to
fail on certain distributions (AFAIK Fedora & ArchLinux).
The failure happen because the thread don't set the current frame to
the most relevant one. So the stopped location doesn't match with what
the test is expecting.
The test will be enabled again after I'll be able to reproduce the failure
on one of those platform and fix the issue.
Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
EXCLUDE_FROM_ALL means something else for add_lit_testsuite as it does
for something like add_executable. Distinguish between the two by
renaming the variable and making it an argument to add_lit_testsuite.
Differential revision: https://reviews.llvm.org/D74168
When a thread stops, this checks depending on the platform if the top frame is
an abort stack frame. If so, it looks for an assert stack frame in the upper
frames and set it as the most relavant frame when found.
To do so, the StackFrameRecognizer class holds a "Most Relevant Frame" and a
"cooked" stop reason description. When the thread is about to stop, it checks
if the current frame is recognized, and if so, it fetches the recognized frame's
attributes and applies them.
rdar://58528686
Differential Revision: https://reviews.llvm.org/D73303
Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
This patch has a couple of outstanding issues. The test is not python3
compatible, and it also seems to fail with python2 (at least under some
circumstances) due to an overambitious assertion.
This reverts the patch as well as subsequent fixup attempts:
014ea9337624fe20aca8892e73b6b3f741d8da9e,
f5f70d1c8fbf12249b4b9598f10a10f12d4db029.
4697e701b8cb40429818609814c7422e49b2ee07.
5c15e8e682e365b3a7fcf35200df79f3fb93b924.
3ec28da6d6430a00b46780555a87acd43fcab790.
When a thread stops, this checks depending on the platform if the top frame is
an abort stack frame. If so, it looks for an assert stack frame in the upper
frames and set it as the most relavant frame when found.
To do so, the StackFrameRecognizer class holds a "Most Relevant Frame" and a
"cooked" stop reason description. When the thread is about to stop, it checks
if the current frame is recognized, and if so, it fetches the recognized frame's
attributes and applies them.
rdar://58528686
Differential Revision: https://reviews.llvm.org/D73303
Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
Value::GetValueByteSize() reports the size of a Value as the size of its
underlying CompilerType. However, a host buffer that backs a Value may
be smaller than GetValueByteSize().
This situation arises when the host is only able to partially evaluate a
Value, e.g. because the expression contains DW_OP_piece.
The cleanest fix I've found to this problem is Greg's suggestion, which
is to resize the Value if (after evaluating an expression) it's found to
be too small. I've tried several alternatives which all (in one way or
the other) tried to teach the Value/ValueObjectChild system not to read
past the end of a host buffer, but this was flaky and impractical as it
isn't easy to figure out the host buffer's size (Value::GetScalar() can
point to somewhere /inside/ a host buffer, but you need to walk up the
ValueObject hierarchy to try and find its size).
This fixes an ASan error in lldb seen when debugging a clang binary.
I've added a regression test in test/functionalities/optimized_code. The
point of that test is not specifically to check that DW_OP_piece is
handled a particular way, but rather to check that lldb doesn't crash on
an input that it used to crash on.
Testing: check-lldb, and running the added tests using a sanitized lldb
--
Thanks to Jim for pointing out that an earlier version of this patch,
which simply changed the definition of Value::GetValueByteSize(), would
interact poorly with the ValueObject machinery.
Thanks also to Pavel who suggested a neat way to test this change
(which, incidentally, caught another ASan issue still present in the
original version of this patch).
rdar://58665925
Differential Revision: https://reviews.llvm.org/D73148
The CMakeLists.txt had a typo which meant that check-lldb-repro was
capturing twice instead of capturing and then replaying. This also
uncovered a missing import in lldb-repro.py. This patch fixes both
issues.
This commit adds AVR support to lldb. With this change, it can load a
binary and do basic things like dump a line table.
Not much else has been implemented, that should be done in later
changes.
Differential Revision: https://reviews.llvm.org/D73539
When a thread stops, this checks depending on the platform if the top frame is
an abort stack frame. If so, it looks for an assert stack frame in the upper
frames and set it as the most relavant frame when found.
To do so, the StackFrameRecognizer class holds a "Most Relevant Frame" and a
"cooked" stop reason description. When the thread is about to stop, it checks
if the current frame is recognized, and if so, it fetches the recognized frame's
attributes and applies them.
rdar://58528686
Differential Revision: https://reviews.llvm.org/D73303
Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
This reverts commit 1b12766883006b8aa9d1ff744e57317647aa052a because of
breaking the mac test suite.
I'm not certain this is the cause because of a concurrent build breakage
which masked this problem, but the failure messages are related to
symbol lookup, which makes this very likely.
Summary:
In the spirit of https://reviews.llvm.org/D70846, we only return functions with matching mangled name from Apple/DebugNamesDWARFIndex::GetFunction if eFunctionNameTypeFull is requested.
This speeds up lookup in the presence of large amount of class methods of the same name (a typical examples would be constructors of templates with many instantiations or overloaded operators).
Reviewers: labath
Reviewed By: labath
Subscribers: aprantl, arphaman, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D73191
Explicitly disallow using lldb instead of %lldb in the shell tests. This
is a clever trick that is used by Swift to achieve the same results.
Differential revision: https://reviews.llvm.org/D73289
We were incorrectly parsing the -C argument to breakpoint set as the
column breakpoint, even though according to the help this should be the
breakpoint command. This fixes that by renaming the option to -u, adding
it to help, and adding a test case.
Differential revision: https://reviews.llvm.org/D73284
As explained in Pavel's previous commit message: %lldb is the proper
substitution. Using "lldb" can cause us to execute the system lldb
instead of the one we are testing. This happens at least in standalone
builds.
This causes the toplevel "test-depends" target, which should only build
all the dependencies necessary for running tests, to suddenaly also run
the check-lldb-repro-capture tests.
Instead add check-lldb-repro-capture as a dependency to check-lldb-repro
with a separate explicit add_dependencies call.
This adds a new target check-lldb-repro which runs the shell tests with
the lldb-repo utility. It runs the shell tests twice, once while
capturing a reproducer and then again by replaying that reproducer.
These test are checking for diagnostics printed by the driver. During
replay we only replay the SB API calls made by the driver, so it's
expected that these messages aren't displayed.
The reproducers currently only shadow the command interpreter. It would
be possible to make it work for the Lua interpreter which uses the
IOHandlerEditline under the hood, but the Python one runs a REPL in
Python itself so there's no (straightforward) way to shadow that.
Given that we already capture any API calls, this isn't super high on my
list of priorities.
