The existing SymbolFilePDB only works on Windows, as it is written
against a closed-source Microsoft SDK that ships with their debugging
tools.
There are several reasons we want to bypass this and go straight to the
bits of the PDB, but just to list a few:
More room for optimization. We can't see inside the implementation of
the Microsoft SDK, so we don't always know if we're doing things in the
most efficient way possible. For example, setting a breakpoint on main
of a big program currently takes several seconds. With the
implementation here, the time is unnoticeable.
We want to be able to symbolize Windows minidumps even if not on
Windows. Someone should be able to debug Windows minidumps as if they
were on Windows, given that no running process is necessary.
This patch is a very crude first attempt at filling out some of the
basic pieces.
I've implemented FindFunctions, ParseCompileUnitLineTable, and
ResolveSymbolContext for a limited subset of possible parameter values,
which is just enough to get it to display something nice for the
breakpoint location.
I've added several tests exercising this functionality which are limited
enough to work on all platforms but still exercise this functionality.
I'll try to add as many tests of this nature as I can, but at some
point we'll need a live process.
For now, this plugin is enabled always on non-Windows, and by setting
the environment variable LLDB_USE_NATIVE_PDB_READER=1 on Windows.
Eventually, once it's at parity with the Windows implementation, we'll
delete the Windows DIA-based implementation.
Differential Revision: https://reviews.llvm.org/D53002
llvm-svn: 344154
This adds a basic support of the .debug_rnglists section.
Only the DW_RLE_start_length and DW_RLE_end_of_list entries are supported.
Differential revision: https://reviews.llvm.org/D52981
llvm-svn: 344119
Summary:
When LLDB successfully parses a command (like "expression" in this case) and determines incomplete input, the user can continue typing on multiple lines (in this case "2+3"). This should provide the correct result.
Note that LLDB reverts input from the additional lines, so they are not present in the output.
Reviewers: vsk, davide, aprantl
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D52270
llvm-svn: 343860
Summary:
Add settings to control command echoing:
```
(lldb) settings set interpreter.echo-commands true
(lldb) settings set interpreter.echo-comment-commands true
```
Both settings default to true, which keeps LLDB's existing behavior in non-interactive mode (echo all command inputs to the output).
So far the only way to change this behavior was the `--source-quietly` flag, which disables all output including evaluation results.
Now `echo-commands` allows to turn off echoing for commands, while evaluation results are still printed. No effect if `--source-quietly` was present.
`echo-comment-commands` allows to turn off echoing for commands in case they are pure comment lines. No effect if `echo-commands` is false.
Note that the behavior does not change immediately! The new settings take effect only with the next command source.
LLDB lit test are the main motivation for this feature. So far incoming `#CHECK` line have always been echoed to the output and so they could never fail. Now we can disable it in lit-lldb-init.
Todos: Finish test for this feature. Add to lit-lldb-init. Check for failing lit tests.
Reviewers: aprantl, jasonmolenda, JDevlieghere
Subscribers: friss, lldb-commits
Differential Revision: https://reviews.llvm.org/D52788
llvm-svn: 343859
Currently we reject our own default disassembly-format string because it
contains two backticks which causes everything in between to be
interpreter as an expression by the command interpreter. This patch
fixes that by escaping backticks when dumping format strings.
llvm-svn: 343471
Summary:
This patch implements restoring of the calling convention from PDB.
It is necessary for expressions evaluation, if we want to call a function
of the debuggee process with a calling convention other than ccall.
Reviewers: clayborg, zturner, labath, asmith
Reviewed By: clayborg
Subscribers: teemperor, lldb-commits, stella.stamenova
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D52501
llvm-svn: 343084
Summary:
* This patch fixes hanging of the test in case of using python3, changes callback
function that will be called if the timer ends, changes python interpreter to
`%python` that is set up by llvm-lit.
* Also, the test didn't work properly since it didn't contain a call of
filecheck_proc.communicate(), that means that filecheck didn't run and its
return code was equal to 0 in all cases.
Reviewers: teemperor, labath, tatyana-krasnukha, aprantl
Reviewed By: teemperor, labath
Subscribers: ki.stfu, lldb-commits
Differential Revision: https://reviews.llvm.org/D52498
llvm-svn: 343033
Summary:
The target-select-so-path test might hang on
some platforms. The reason of that behavior
was in incorrect usage of Filecheck and lldb-mi
processes. Instead of redirecting lldb-mi's output
to Filecheck, we should run lldb-mi session,
finish the session, collect its output and then pass
it to Filecheck.
Also, this patch adds a timer to the test to prevent
it from hanging in the future.
Reviewers: tatyana-krasnukha, aprantl, teemperor
Reviewed By: tatyana-krasnukha, teemperor
Subscribers: apolyakov, aprantl, teemperor, ki.stfu, abidh, lldb-commits
Differential Revision: https://reviews.llvm.org/D52139
llvm-svn: 342915
Summary:
The test failed in case of compiling a test suite with
gcc (checked versions are 5.2.0 and 7.3.0) because it
adds one more line entry comparing to clang. It doesn't
break the test's logic, so I just added a regex that matches
this case.
Reviewers: tatyana-krasnukha, aprantl, clayborg
Reviewed By: aprantl
Subscribers: ki.stfu, lldb-commits
Differential Revision: https://reviews.llvm.org/D52101
llvm-svn: 342329
Summary:
This patch adds an implementation of retrieving of declarations and declaration
contexts based on PDB symbols.
PDB has different type symbols for const-qualified types, and this
implementation ensures that only one declaration was created for both const
and non-const types, but creates different compiler types for them.
The implementation also processes the case when there are two symbols
corresponding to a variable. It's possible e.g. for class static variables,
they has one global symbol and one symbol belonging to a class.
PDB has no info about namespaces, so this implementation parses the full symbol
name and tries to figure out if the symbol belongs to namespace or not,
and then creates nested namespaces if necessary.
Reviewers: asmith, zturner, labath
Reviewed By: asmith
Subscribers: aleksandr.urakov, teemperor, lldb-commits, stella.stamenova
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D51162
llvm-svn: 341782
Summary:
`dwarf5-index-is-used.cpp` have been failing after rL340206, because `clang`
have stopped to emit pubnames by default after that change. Current patch adds
`-gpubnames` option to the `clang` command line in the test to emit pubnames.
Reviewers: labath, dblaikie
Reviewed By: labath
Subscribers: clayborg, probinson, teemperor, lldb-commits, aprantl, JDevlieghere, abidh, stella.stamenova
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D51208
llvm-svn: 341296
presumably the or subexpression was meant to be evaluated first. The way
it is now means that we apply the workaround for any python in `/usr`,
which matches pretty much every unix system.
llvm-svn: 341167
Summary:
This patch allows to resolve a symbol context block info even if a function
info was not requested. Also it adds the correct resolving of nested blocks
(the previous implementation used function blocks instead of them).
Reviewers: zturner, asmith, labath
Reviewed By: asmith
Subscribers: lldb-commits, stella.stamenova
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D51104
llvm-svn: 340901
Summary:
LLDB currently only checks the output terminal for color support by looking
at the `TERM` environment variable and comparing it to `"dumb"`. This causes that
when running LLDB on a CI node, the syntax highlighter will not be deactivated by
LLDB and the output log is filled with color codes (unless the terminal emulator
actually exposes itself as dumb).
This patch now relies on the LLVM code for detecting color support which is more
reliable. We now also correctly actually initialize the `m_supports_colors` variable in `File`.
`m_supports_colors` was so far uninitialized, but the code path that uses `m_supports_colors`
was also dead so the sanitizers didn't sound an alarm.
The old check that compares `TERM` is not removed by this patch as the new LLVM code
doesn't seem to handle this case (and it's a good thing to check for "dumb" terminals).
Reviewers: aprantl, javed.absar
Reviewed By: aprantl
Subscribers: kristof.beyls, abidh, lldb-commits
Differential Revision: https://reviews.llvm.org/D51243
llvm-svn: 340747
Summary:
`variables.test` depends on mangled names, but the mangling depends
on the bitness. This patch specifies the bitness explicitly, so mangled names
doesn't differ when a 32-bit version of the compiler is used.
Reviewers: stella.stamenova, asmith
Reviewed By: stella.stamenova
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D51158
llvm-svn: 340597
Summary:
In this patch I've tried to combine the best ideas from D49368 and D49410,
so it implements following:
- Completion of UDTs from a PDB with a filling of a layout info;
- Pointers to members;
- Fixes the bug relating to a virtual base offset reading from `vbtable`.
The offset was treated as an unsigned, but it can be a negative sometimes.
- Support of MSInheritance attribute
Reviewers: asmith, zturner, rnk, labath, clayborg, lldb-commits
Reviewed By: zturner
Subscribers: aleksandr.urakov, stella.stamenova, JDevlieghere, lldb-commits
Differential Revision: https://reviews.llvm.org/D49980
llvm-svn: 339649
This test relies on communicating with debugserver via an unnamed (pre-opened)
pipe, but macOS's version of debugserver doesn't seem to support that mode of
operation. So disable the test for now.
llvm-svn: 339343
Double quotes are always correct in paths on windows while single quotes only work sometimes. By swapping the order of the quotes in the subsitution we guarantee that the quotes will be correct on Windows. Both sets work correctly on Linux in the test environment.
llvm-svn: 339180
Now target-select uses SB API instead of HandleCommand.
This patch has been reviewed along with the r339175.
Differential Revision: https://reviews.llvm.org/D49739
llvm-svn: 339178
This change improves the logging for the lldb.module category to note a few interesting cases:
1. Local object file found, but specs not matching
2. Local object file not found, using a placeholder module
The handling and logging for the cases wehre we fail to load compressed dwarf
symbols is also improved.
Differential Revision: https://reviews.llvm.org/D50274
llvm-svn: 339161
Summary:
The issue with the python path is that the path to python on Windows can contain spaces. To make the tests always work, the path to python needs to be surrounded by quotes.
This is a companion change to: https://reviews.llvm.org/D50206
Reviewers: asmith, zturner
Differential Revision: https://reviews.llvm.org/D50280
llvm-svn: 339076
The new test checks that we are actually able to read data from these
kinds of elf headers correctly instead of just that we read the section
number correctly. It is also easier to figure out what's going on in the
test.
llvm-svn: 337459
Summary: This one fixes variables.test after D49018. The test was broken because D49018 adds a location information to variables, but I hadn't noticed that, because I used 32-bit build to run tests, so the test looked to me already broken before that commit (the test relies on mangled names, but the mangling schemes are different for 32-bit and 64-bit).
Reviewers: stella.stamenova, lldb-commits
Reviewed By: stella.stamenova
Patch By: Aleksandr Urakov
Differential Revision: https://reviews.llvm.org/D49475
llvm-svn: 337397
Summary: Several tests exist in both lit and lldbsuite. This removes the lit version of the duplicated tests.
Reviewers: asmith, zturner
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D49450
llvm-svn: 337393
llvm-lit uses `map_config` directives (generated at configuration-time) to
make it possible to pass a test path relative to the source instead of
the build folder (CMAKE_CURRENT_BINARY_DIR).
However, this doesn't work in the case of swift where the build
directory layout prevents llvm-lit from knowing about lldb and its test
paths. This caused check-lldb-unit to fail in this configuration, while
everything was working as expected upstream. This patch fixes the issue
by passing a path relative to the build directory. This was already the
case for check-lldb-lit.
llvm-svn: 337291
Wrong FileCheck header meant that we were not matching what we should.
This allows us to get rid of the -allow-deprecated-dag-overlap flag in
the test.
llvm-svn: 337188
The current version of SymbolFilePDB::ParseVariableForPDBData function
always initializes variables with an empty location. This patch adds the
converter of a location information from PDB to a DWARF expression, so
it becomes possible to watch values of variables of primitive data
types. At the moment the converter supports only Static, TLS, RegRel,
Enregistered and Constant PDB location types, but it seems that it's
enough for most cases. There are still some problems with retrieving
values of variables (e.g. we can't watch variables of composite types),
but they look not relevant to the conversion to DWARF.
Patch by: Aleksandr Urakov
Differential revision: https://reviews.llvm.org/D49018
llvm-svn: 336988
Summary:
This patch adds the possibility to specify an exit code when calling quit.
We accept any int, even though it depends on the user what happens if the int is
out of the range of what the operating system supports as exit codes.
Fixes rdar://problem/38452312
Reviewers: davide, jingham, clayborg
Reviewed By: jingham
Subscribers: clayborg, jingham, lldb-commits
Differential Revision: https://reviews.llvm.org/D48659
llvm-svn: 336824
Summary:
This patch fixes a problem with retrieving a function symbol by an address in a nested block. In the current implementation of ResolveSymbolContext function it retrieves a symbol with PDB_SymType::None and then checks if found symbol's tag equals to PDB_SymType::Function. So, if nested block's symbol was found, ResolveSymbolContext does not resolve a function.
It is very simple to reproduce this. For example, in the next program
```
int main() {
auto r = 0;
for (auto i = 1; i <= 10; i++) {
r += i & 1 + (i - 1) & 1 - 1;
}
return r;
}
```
if we will stop inside the cycle and will do a backtrace, the top element will be broken. But how we can test this? I thought to add an option to lldb-test to allow search a function by address, but the address may change when the compiler will be changed.
Patch by: Aleksandr Urakov
Reviewers: asmith, labath, zturner
Reviewed By: asmith, labath
Subscribers: stella.stamenova, llvm-commits
Differential Revision: https://reviews.llvm.org/D47939
llvm-svn: 336564
This patch removes the requirement for a semicolon as a separator when
passing arguments to lit. It relies on the shlex module that is part of
Python to do simple lexical analysis, similar to what happens in a Unix
shell.
llvm-svn: 336290
Summary:
This test makes sure we are able to read the shorter build-ids which are
generated by lld.
To make this work, I've extended lldb-test to print the UUID of the
loaded object file. I've renamed the lldb-test subcommand from
"module-sections" to "object-file" to reflect the fact it prints more
than just the sections.
I've also added the module Architecture to the output, so we could avoid
printing the entire symbol file information just to get the ArchSpec
details in the lc_version_min test (which was also the only test in it's
folder not using the module-sections command).
Reviewers: aprantl, zturner
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D48646
llvm-svn: 335967
Summary:
This patch fixes a problem with retrieving a function symbol by an
address in a nested block. In the current implementation of
ResolveSymbolContext function it retrieves a symbol with
PDB_SymType::None and then checks if found symbol's tag equals to
PDB_SymType::Function. So, if nested block's symbol was found,
ResolveSymbolContext does not resolve a function.
Reviewers: asmith, labath, zturner
Reviewed By: asmith, labath
Differential Revision: https://reviews.llvm.org/D47939
Patch by Aleksandr Urakov <aleksandr.urakov@jetbrains.com>
llvm-svn: 335822
This fixes a silly bug where we were accidentally freeing the memory
used to store the decompressed .debug_names data. I had actually
considered this scenario when writing the class and put appropriate
precautions in place -- I just failed to wire it all up correctly.
This was only an issue for compressed sections because in case of
uncompressed ones we would access the data straight out of the mmapped
object file.
llvm-svn: 334717
The motivation for this is to be able to Dwarf index ability to look up
variables within a given compilation unit. It also fits in with the
patch in progress at D47939, which will add the ability to look up
funtions using file+line pairs.
The verification of which lldb-test options can be used together was
getting a bit unwieldy, so I moved the logic out into a separate
function.
llvm-svn: 334498
The getDIESectionOffset function is not correct for split dwarf files
(and will probably be removed in D48009).
This patch implements correct section offset computation for split and
non-split compile units -- we first need to check if the referenced unit
is a skeleton unit, and if it is, we add the die offset to the full unit
base offset (as the full unit is the one which contains the die).
llvm-svn: 334402
This also fixes a bug where SymbolFileDWARF was returning the same
function multiple times - this can happen if both mangled and demangled
names match the regex. Other lookup lookup functions had code to handle
this case, but it was forgotten here.
llvm-svn: 334277
Summary:
This patch implements the non-regex variant of GetFunctions. To share
more code with the Apple implementation, I've extracted the common
filtering code from that class into a utility function on the DWARFIndex
base class.
The new implementation also searching the accelerator table multiple
times -- previously it could happen that the apple table would return
the same die more than once if one specified multiple search flags in
name_type_mask. This way, I separate table iteration from filtering, and
so we can be sure each die is inserted at most once.
Reviewers: clayborg, JDevlieghere
Subscribers: aprantl, lldb-commits
Differential Revision: https://reviews.llvm.org/D47881
llvm-svn: 334273
Summary:
The patch adds support of splitted functions (when MSVC is used with PGO) and function-level linking feature.
SymbolFilePDB::ParseCompileUnitLineTable function relies on fact that ranges of compiled source files in the binary are continuous and don't intersect each other. The function creates LineSequence for each file and inserts it into LineTable, and implementation of last one relies on continuity of the sequence. But it's not always true when function-level linking enabled, e.g. in added input test file test-pdb-function-level-linking.exe there is xstring's std__basic_string_char_std__char_traits_char__std__allocator_char_____max_size (.00454820) between test-pdb-function-level-linking.cpp's foo (.00454770) and main (.004548F0).
To fix the problem this patch renews the sequence on each address gap.
Reviewers: asmith, zturner
Reviewed By: asmith
Subscribers: aleksandr.urakov, labath, mgorny, lldb-commits
Differential Revision: https://reviews.llvm.org/D47708
llvm-svn: 334260
Summary: They all correspond to bugs that are already logged and I've added the appropriate (or most appropriate) bug numbers. This leaves only a handful of failing tests.
Reviewers: asmith, zturner, labath
Reviewed By: zturner
Subscribers: eraman, llvm-commits
Differential Revision: https://reviews.llvm.org/D47892
llvm-svn: 334210
This implements just one of the GetTypes overloads. The other is not
testable from lldb-test so I'm leaving it unimplemented until I figure
out what to do with testing.
llvm-svn: 334190
Summary:
It possible that a single module has indexed and non-indexed compile
units. In this case, we can use the fast indexed lookup for the first
ones and fall back to the manual index for the others.
This patch implements this functionality by adding a units_to_avoid
argument to the ManualDWARFIndex constructor. Any units present in that
list will be ignored for the purposes of manual index. Individual
DebugNamesDWARFIndex then always consult both the manual fallback index
as well as the index in the .debug_names section.
Reviewers: JDevlieghere, clayborg
Subscribers: aprantl, lldb-commits
Differential Revision: https://reviews.llvm.org/D47832
llvm-svn: 334185
Summary:
This patch adds the ability to lookup variables to the DWARF v5 index
class.
During review we discovered an inconsistency between how the existing
two indexes handle looking up qualified names of the variables:
- manual index would return a value if the input string exactly matched
the demangled name of some variable.
- apple index ignored the context and returned any variable with the
same base name.
So, this patch also rectifies that situation:
- it removes all context handling from the index classes. The
GetGlobalVariables functions now just take a base name. For manual
index, this meant we can stop putting demangled names into the
variable index (this matches the behavior for functions).
- context extraction is put into SymbolFileDWARF, so that it is common
to all indexes.
- additional filtering based on the context is also done in
SymbolFileDWARF. This is done via a simple substring search, which is
not ideal, but it matches what we are doing for functions (cf.
Module::LookupInfo::Prune).
Reviewers: clayborg, JDevlieghere
Subscribers: aprantl, lldb-commits
Differential Revision: https://reviews.llvm.org/D47781
llvm-svn: 334181
Summary:
This patch adds the skeleton for implementing the DWARF v5 name index
class. All of the methods are stubbed out and will be implemented in
subsequent patches. The interesting part of the patch is the addition of
a "ignore-file-indexes" setting to the dwarf plugin which enables a
user to force using manual indexing path in lldb (for example as a
debugging aid). I have also added a test that verifies that file indexes
are used by default.
Reviewers: JDevlieghere, clayborg, jingham
Subscribers: mgorny, mehdi_amini, aprantl, lldb-commits
Differential Revision: https://reviews.llvm.org/D47629
llvm-svn: 334088
Skip all Python-based tests as unsupported when LLDB_DISABLE_PYTHON is
enabled. Otherwise, those tests simply fail being unable to import lldb
module.
Differential Revision: https://reviews.llvm.org/D47812
llvm-svn: 334080
Summary: This test was failing sporadically on windows because the order in which the symbols are generated was different between builds. To fix the test, we need to run FileCheck twice - once for each set of symbols we want to verify. The test only runs on Windows.
Reviewers: asmith, zturner, labath
Subscribers: stella.stamenova, llvm-commits
Differential Revision: https://reviews.llvm.org/D47746
llvm-svn: 334025
Summary:
The default name for a compiler output on Linux is `a.out`,
while on Windows it's `a.exe`. But if we add option `-o a.exe`,
the compiler will create the executable `a.exe` on the both systems.
Reviewers: aprantl, stella.stamenova
Reviewed By: stella.stamenova
Subscribers: ki.stfu, llvm-commits, lldb-commits
Differential Revision: https://reviews.llvm.org/D47679
llvm-svn: 333963
Change the syntax of the malloc and free commands in lldb-test's
ir-memory-map subcommand to:
<malloc> ::= <label> = malloc <size> <alignment>
<free> ::= free <label>
This should make it easier to read and extend tests in the future, e.g
to test IRMemoryMap::WriteMemory or double-free behavior.
Differential Revision: https://reviews.llvm.org/D47646
llvm-svn: 333930
Add OpenBSD python module in order to support unit tests.
Reviewers: labath, zturner
Reviewed By: labath
Differential Revision: https://reviews.llvm.org/D47692
llvm-svn: 333888
Summary:
When searching for methods only, we need to do extra work to make sure
the functions we get from the apple tables are indeed methods.
Previously we were resolving the DIE into a SymbolContext and then
checked whether the enclosing CompilerDeclContext is a
class (or struct, or union).
This patch changes that to operate on the debug info directly. This
should be:
- simpler
- faster
- more consistent with the ManualDWARFIndex (which does the same check,
only at indexing time).
What we lose this ways is for the language plugin to have a say in what
it considers to be a "class", but that's probably more flexibility than
we need (and if we really wanted to do that in the future, we could
implement a more direct way to consult the plugin about this).
This also fixes the find-method-local-struct test, which was failing
because we were not able to construct a CompilerDeclContext for a local
struct correctly.
As a drive-by, I rename the DWARFDIE's IsStructClassOrUnion method to
match the name on the CompilerDeclContext class.
Reviewers: clayborg, JDevlieghere
Subscribers: aprantl, lldb-commits
Differential Revision: https://reviews.llvm.org/D47470
llvm-svn: 333878
Summary: One of the tests is failing to build because it needs GS-, the second test does not correctly match all the expected function names because newer DIA SDKs annotate the function names with their return type and inputs (e.g. "static long `anonymous namespace'::StaticFunction(int)")
Reviewers: asmith, zturner
Reviewed By: zturner
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D47653
llvm-svn: 333790
Summary: Skip the new break-insert test on Windows because it hangs and so the test suite never completes. All other lldb-mi tests in the test suite are also skipped on windows
Reviewers: asmith, aprantl, polyakov.alex
Reviewed By: aprantl
Subscribers: ki.stfu, llvm-commits
Differential Revision: https://reviews.llvm.org/D47651
llvm-svn: 333789
It's been pointed out in https://reviews.llvm.org/D47646 that lldb-test
fails to create a usable process on Windows when running this test.
llvm-svn: 333785
This adds a new command to the ir-memory-map tester:
free <allocation-index>
The argument to free is an index which identifies which live allocation
to free. Index 0 identifies the first live allocation in the address
space, index 1 identifies the second, etc. where the allocations are
sorted in increasing order.
For illustrative purposes, assume malloc returns monotonically
increasing addresses. Here are some examples of how free would work:
Example 1
---------
malloc 16 1
malloc 32 1
free 1 //< Free the 32-byte allocation.
free 0 //< Next, free the 16-byte allocation.
Example 2
---------
malloc 16 1
malloc 32 1
free 0 //< Free the 16-byte allocation.
free 0 //< Next, free the 32-byte allocation.
llvm-svn: 333700
r333583 introduced testing for IRMemoryMap's process-side allocations
(eAllocationPolicyProcessOnly). This adds support for the host-side
variety (eAllocationPolicyHostOnly).
llvm-svn: 333698
This prevents Malloc from allocating the same chunk of memory twice, as
a byproduct of an alignment adjustment which gave the client access to
unallocated memory.
Prior to this patch, the newly-added test failed with:
$ lldb-test ir-memory-map ... ir-memory-map-overlap1.test
...
Command: malloc(size=64, alignment=32)
Malloc: address = 0x1000cd080
Command: malloc(size=64, alignment=8)
Malloc: address = 0x1000cd0b0
Malloc error: overlapping allocation detected, previous allocation at [0x1000cd080, 0x1000cd0c0)
Differential Revision: https://reviews.llvm.org/D47551
llvm-svn: 333697
This teaches lldb-test how to launch a process, set up an IRMemoryMap,
and issue memory allocations in the target process through the map. This
makes it possible to test IRMemoryMap in a targeted way.
This has uncovered two bugs so far. The first bug is that Malloc
performs an adjustment on the pointer returned from AllocateMemory (for
alignment purposes) which ultimately allows overlapping memory regions
to be created. The second bug is that after most of the address space on
the host side is exhausted, Malloc may return the same address multiple
times. These bugs (and hopefully more!) can be uncovered and tested for
with targeted lldb-test commands.
At an even higher level, the motivation for addressing these bugs is
that they can lead to strange user-visible failures (e.g, variables
assume the wrong value during expression evaluation, or the debugger
crashes). See my third comment on this swift-lldb PR for an example:
https://github.com/apple/swift-lldb/pull/652
I hope lldb-test is the right place to add this testing harness. Setting
up a gtest-style unit test proved too cumbersome (you need to recreate
or mock way too much debugger state), as did writing end-to-end tests
(it's hard to write a test that actually hits a buggy path).
With lldb-test, it's easy to read/generate the test input and parse the
test output. I'll attach a simple "fuzz" tester which generates failing
test cases to the Phab review. Here's an example:
```
Command: malloc(size=1024, alignment=32)
Malloc: address = 0xca000
Command: malloc(size=64, alignment=16)
Malloc: address = 0xca400
Command: malloc(size=1024, alignment=16)
Malloc: address = 0xca440
Command: malloc(size=16, alignment=8)
Malloc: address = 0xca840
Command: malloc(size=2048, alignment=16)
Malloc: address = 0xcb000
Command: malloc(size=64, alignment=32)
Malloc: address = 0xca860
Command: malloc(size=1024, alignment=16)
Malloc: address = 0xca890
Malloc error: overlapping allocation detected, previous allocation at [0xca860, 0xca8a0)
```
{F6288839}
Differential Revision: https://reviews.llvm.org/D47508
llvm-svn: 333583
The lldb test suite is highly configurable. While part of this
configuration takes place at configure/build-time, a common scenario
involves running the test suite several times with different
configuration. For example, we might want to test the current lldb
against inferiors built with different compilers.
This configuration was already possible for lldb-dotest, but was lacking
for the lit counterpart. It is now possible to pass arguments to pass
arguments like this:
./bin/llvm-lit ../llvm/tools/lldb/lit/Suite/ -Ddotest-args="-foo;-bar"
llvm-svn: 333432
Summary:
We were treating subprograms and inlined subroutines differently when
building the index. The difference was in which indexes were individual
tags inserted (subprograms went to all indexes, where as inlined
subroutines only into the basename and full name indexes).
This seems like an error, because an inlined subroutine can still
represent an C++ or an ObjC method. I don't see anything in the
subprogram branch which should not apply to an inlined subroutine, so I
propose to just treat them identically. This makes searching for an
inlined method behave the same way as for the apple index.
I write an assembly-based test because I did not want to depend on
particular clang inlining behavior (and because I wanted to see how hard
would it be).
Reviewers: clayborg, JDevlieghere
Subscribers: eraman, lldb-commits
Differential Revision: https://reviews.llvm.org/D47368
llvm-svn: 333398
Now it's possible to set breakpoints before selecting a target, they
will be set to the dummy target and then copied to an each added one.
Patch by Alexander Polyakov!
Differential Revision: https://reviews.llvm.org/D46588
llvm-svn: 333205
Summary:
Implement FindGlobalVariables and ParseVariableContext methods.
Compile unit information is necessary for resolving variable context, however some PDB symbols do not have this information. For now an empty DWARFExpression is used to construct a lldb::Variable instance with the limitation that using lldb to lookup the value of a global or local variable is not available.
This commit may slow down lit/SymbolFile/PDB/compilands.test since the test includes MS specific modules that spend more time parsing variables.
Reviewers: rnk, zturner, lldb-commits
Subscribers: aprantl, JDevlieghere, llvm-commits
Differential Revision: https://reviews.llvm.org/D45224
llvm-svn: 333049
After closer examination, it turns out we mis-classify one of the
methods only if two of the structs have the same name. Since this was
meant to be a basic test, I rename one of the structs in the test so
that we have at least some coverage for the apple tables lookup.
Instead, I create an XFAILed test which specifically targets the
same-name case (and file a bug to track it).
llvm-svn: 332833
Summary:
Now that we are able to parse MachO files everywhere, we can write some
cross-platform tests for handling of apple accelerator tables. This
reruns the same lookup tests we have for manual indexes on MachO files
which will use the accelerator tables instead. This makes sure we return
the same results regardless of the method we used to access the debug
info.
The tests confirm we return the same results for looking up types,
namespaces and variables, but have found an inconsistency in the
treatment of function lookup. In the function case we mis-classify the
method "foo" declared in the local struct sbar (inside function ffbar).
We classify it as a function whereas it really is a method. Preliminary
analysis suggests this is because
DWARFASTParserClang::GetClangDeclContextForDIE returns null when given
the local "struct sbar" DIE. This causes us to get the wrong
CompilerDeclContext when we ask for the context of the inner foo, which
means CompilerDeclContext::ISStructUnionOrClass returns false.
Until this is fixed, I do not include the darwin versions of the "base"
and "method" function lookup tests.
Reviewers: JDevlieghere, clayborg
Subscribers: aprantl, ilya-biryukov, ioeric, lldb-commits
Differential Revision: https://reviews.llvm.org/D47064
llvm-svn: 332831
Summary:
Before this patch we were unable to write cross-platform MachO tests
because the parsing code did not compile on other platforms. The reason
for that was that ObjectFileMachO depended on
RegisterContextDarwin_arm(64)? (presumably for core file parsing) and
the two Register Context classes uses constants from the system headers
(KERN_SUCCESS, KERN_INVALID_ARGUMENT).
As far as I can tell, these two files don't actually interact with the
darwin kernel -- they are used only in ObjectFileMachO and MacOSX-Kernel
process plugin (even though it has "kernel" in the name, this one
communicates with it via network packets and not syscalls). For the time
being I have created OS-independent definitions of these constants and
made the register context classes use those. Long term, the error
handling in these classes should be probably changed to use more
standard mechanisms such as Status or Error classes.
This is the only change necessary (apart from build system glue) to make
ObjectFileMachO work on other platforms. To demonstrate that, I remove
REQUIRES:darwin from our (only) cross-platform mach-o test.
Reviewers: jasonmolenda, aprantl, clayborg, javed.absar
Subscribers: mgorny, lldb-commits, kristof.beyls
Differential Revision: https://reviews.llvm.org/D46934
llvm-svn: 332702
Getting the deployment target can be significant information when
rebuilding clang modules since availability information could depend
on it.
rdar://problem/40039633
Differential Revision: https://reviews.llvm.org/D46669
llvm-svn: 332067
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 patch restructures part of LLDB's testing configuration:
1. I moved the test dependencies up the chain so every dotest dependency
becomes a lit dependency as well. It wouldn't make sense for dotest to
have other dependencies when it's being run by lit. Lit on the other
hand can still specify extra dependencies.
2. I replaced as much generator expressions with variables as possible.
This is consistent with the rest of LLVM and doesn't break generators
that support multiple targets (MSVC, Xcode). This wasn't a problem
before, but now we need to expand the dotest arguments in the lit
configuration and there's only one test suite even with multiple
targets.
3. I moved lldb-dotest into it's own directory under utils since there's
no need anymore for it to located under `test/`.
Differential revision: https://reviews.llvm.org/D46334
llvm-svn: 331463
Summary:
lldb-test already had the ability to dump all symbol information in a
module. This is interesting, but it can be too verbose, and it also does
not use the same APIs that lldb uses to query symbol information. The
last part is interesting to me now, because I am about to add DWARF v5
debug_names support, which needs to implement these APIs.
This patch adds a set of arguments to lldb-test, which modify it's
behavior from dumping all symbols to dumping only the requested
information:
- --find={function,namespace,type,variable} - search for the given
kind of objects.
- --name - the name to search for.
- --regex - whether to treat the "name" as a regular expression. This is
not available for all lookup types (we do not have the required APIs
for namespaces and types).
- --context - specifies the context, which can be used to restrict the
search. This argument takes a variable name (which must be defined and
be unique), and we then use the context that this variable is defined
in as the search context.
- --function-flags={auto,full,base,method,selector} - a set of flags to
further restrict the search for function symbols.
Together, these flags and their combinations cover the main SymbolFile
entry points which I will need to modify for the accelerator table
support, and so I plan to do most of the regression testing this way.
(I've also found this a useful tool for exploration of what the given
APIs are supposed to do.)
I add a couple of tests to demonstrate the usage of the usage of the
various options, and also an xfailed test which demonstrates a bug I
found while playing with this. The only requirement for these tests is
the presence of lld -- the should run on any platform which is able to
build lldb.
These tests use c++ code as input, but this isn't a requirement. It is also
possible to use IR, assembly or json to create the test module.
Reviewers: davide, zturner, asmith, JDevlieghere, clayborg, alexshap
Subscribers: mgorny, aprantl, lldb-commits
Differential Revision: https://reviews.llvm.org/D46318
llvm-svn: 331447
ObjectFileELF assumes that code section has ".text" name. There is an
exception for kalimba toolchain that can use arbitrary names, but other
toolchains also could use arbitrary names for code sections. For
example, corert uses separate section for compiled managed code. As lldb
doesn't recognize such section it leads to problem with breakpoints on
arm, because debugger cannot determine instruction set (arm/thumb) and
uses incorrect breakpoint opcode that breaks program execution.
This change allows debugger to correctly handle such code sections. We
assume that section is a code section if it has SHF_EXECINSTR flag set
and has SHT_PROGBITS type.
Patch by Konstantin Baladurin <k.baladurin@partner.samsung.com>.
Differential Revision: https://reviews.llvm.org/D44998
llvm-svn: 331173
Summary:
The new script to run the lldbtests as part of lit invokes each test by calling dotest.py, however, we cannot rely on the system to always correctly interpret the script as python causing the tests to be unresolved on windows (at least). To fix this, we need to make sure that the first parameter in the command line is the python executable itself.
In Makefile.rules, there are a number of windows specific definitions that rely on the HOST_OS being set as Windows_NT but the logic detecting the OS currently does not detect server versions of windows correctly. This change updates the logic to detect windows server as well.
Reviewers: asmith, labath, JDevlieghere, zturner
Reviewed By: JDevlieghere, zturner
Subscribers: zturner, llvm-commits
Differential Revision: https://reviews.llvm.org/D46020
llvm-svn: 330740
The current way that the lit configuration is generated for the LLDB
tests that run using dotest causes cmake to fail when using a generator
which supports multiple configurations (such as Visual Studio). The
failure is because file GENERATE will create a file *per possible
configuration* resulting in the same lit configuration file being
overwritten multiple times.
To fix the issue, we need to create a single lit file that is agnostic
of the configurations and can be used for any configuration.
Patch by: Stella Stamenova
Differential revision: https://reviews.llvm.org/D45918
llvm-svn: 330518
This is the first in what will hopefully become a series of patches to
replace the driver logic in dotest.py with LIT. The motivation for this
change is that there's no point in maintaining two driver
implementations. Since all of the LLVM projects are using lit, this is
the obvious choice.
Obviously the goal is maintain full compatibility with the functionality
offered by dotest. As such we won't be removing anything until that
point has been reached.
This patch is the initial attempt (referred to as v1) to run the lldb
test suite with lit. To do so we introduced a custom LLDB test format
that invokes dotest.py with a single test file.
Differential revision: https://reviews.llvm.org/D45333
llvm-svn: 330275
Zachary Turner