This adds support to LLDB for named types (class, struct, union, and
enum). This is true cross platform support, and hits the PDB file
directly without a dependency on Windows. Tests are added which
compile a program with certain interesting types and then use
load the target in LLDB and use "type lookup -- <TypeName>" to
dump the layout of the type in LLDB without a running process.
Currently only fields are parsed -- we do not parse methods. Also
we don't deal with bitfields or virtual bases correctly. Those
will make good followups.
Differential Revision: https://reviews.llvm.org/D53511
llvm-svn: 345047
DWARF5 describes DW_RLE_start_end as:
This is a form of bounded range entry that has two target address operands.
Each operand is the same size as used in DW_FORM_addr. These indicate
the starting and ending addresses, respectively, that define the address range
for which the following location is valid.
The patch implements the support.
Differential revision: https://reviews.llvm.org/D53193
llvm-svn: 344674
This adds -- before any filenames, so that /U doesn't get interpreted
as a command line.
It also adds better error checking, so that we don't get assertions
on the failure path when a file fails to parse as a PDB.
llvm-svn: 344429
This was originally reverted due to some test failures on
Linux. Those problems turned out to require several additional
patches to lld and clang in order to fix, which have since been
submitted. This patch is resubmitted unchanged. All tests now
pass on both Linux and Windows.
llvm-svn: 344409
LLDB does not support this DWARF5 form atm.
At least gcc emits it in some cases when doing optimization
for abbreviations.
As far I can tell, clang does not support it yet, though
the rest LLVM code already knows about it.
The patch adds the support.
Differential revision: https://reviews.llvm.org/D52689
llvm-svn: 344328
This was originally causing some test failures on non-Windows
platforms, which required fixes in the compiler and linker. After
those fixes, however, other tests started failing. Reverting
temporarily until I can address everything.
llvm-svn: 344279
While it doesn't make a *ton* of sense for POSIX paths to be
in PDBs, it's possible to occur in real scenarios involving
cross compilation.
The tools need to be able to handle this, because certain types
of debugging scenarios are possible without a running process
and so don't necessarily require you to be on a Windows system.
These include post-mortem debugging and binary forensics (e.g.
using a debugger to disassemble functions and examine symbols
without running the process).
There's changes in clang, LLD, and lldb in this patch. After
this the cross-platform disassembly and source-list tests pass
on Linux.
Furthermore, the behavior of LLD can now be summarized by a much
simpler rule than before: Unless you specify /pdbsourcepath and
/pdbaltpath, the PDB ends up with paths that are valid within
the context of the machine that the link is performed on.
Differential Revision: https://reviews.llvm.org/D53149
llvm-svn: 344269
LC_BUILD_VERSION load command handling - this
commit is a combination of patches by Adrian
Prantl and myself. llvm::Triple::BridgeOS
isn't defined yet, so all references to that
are currently commented out.
Also update Xcode project file to build the
NativePDB etc plugins.
<rdar://problem/43353615>
llvm-svn: 344209
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
Instead of applying the sledgehammer of refusing to insert any
C++ symbol in the ASTContext, try to validate the decl if what
we have is an operator. There was other code in lldb which was
responsible for this, just not really exposed (or used) in this
codepath. Also, add a better/more comprehensive test.
<rdar://problem/35645893>
llvm-svn: 328025
Until we have a better story for putting commands and check lines
in the same file (they're currently ignored), it seems that inline
tests are actually more concise and easier to understand.
Too bad we have still some python boilerplate, but that's not
really substantial so we can live with it.
Thanks to Fred for pointing out and Jim for explaining me how
to use the inline test format.
<rdar://problem/34806516>
llvm-svn: 327592
Before the patch:
(lldb) frame var emptyDictionary
(__NSDictionary0 *) emptyDictionary = 0x0000000100304420
After:
(lldb) frame var emptyDictionary
(__NSDictionary0 *) emptyDictionary = 0x0000000100304420 0 key/value pairs
There's nothing much else we can do, as this is always empty by
definition.
<rdar://problem/34806516>
llvm-svn: 327587
Typical example, illformed comparisons (operator== where LHS and
RHS are not compatible). If a symbol matched `operator==` in any
of the object files lldb inserted a generic function declaration
in the ASTContext on which Sema operates. Maintaining the AST
context invariants is fairly tricky and sometimes resulted in
crashes inside clang (or assertions hit).
The real reason why this feature exists in the first place is
that of allowing users to do something like:
(lldb) call printf("patatino")
even if the debug informations for printf() is not available.
Eventually, we might reconsider this feature in its
entirety, but for now we can't remove it as it would break
a bunch of users. Instead, try to limit it to non-C++ symbols,
where getting the invariants right is hopefully easier.
Now you can't do in lldb anymore
(lldb) call _Zsomethingsomething(1,2,3)
but that doesn't seem to be such a big loss.
<rdar://problem/35645893>
llvm-svn: 327356
This is a more principled approach to disabling Spotlight .dSYM
lookups while running the testsuite, most importantly it also works
for the LIT-based tests, which I overlooked in my initial fix
(renaming the test build dir to lldb-tests.noindex).
Differential Revision: https://reviews.llvm.org/D44342
llvm-svn: 327330
This reverts commit r327318. It breaks the Xcode and CMake Darwin
builders:
clang: error: no such file or directory:
'.../source/Plugins/Architecture/PPC64/ArchitecturePPC64.cpp'
clang: error: no input files
More details are in https://reviews.llvm.org/D42582.
llvm-svn: 327327
Summary:
Besides being superfluous, this double merging was actually wrong and
causing some sections to be added twice. The reason for that was that
the code assumes section IDs are unique in the section list, but this is
only true if all sections in the list come from the same object file.
Reviewers: fjricci, jankratochvil
Subscribers: emaste, lldb-commits, arichardson
Differential Revision: https://reviews.llvm.org/D44157
llvm-svn: 327123
There's now a test using llvm-objcopy in lit/.
This doesn't fail on the bot(s) because `llvm-objcopy` is probably
already available there, but if you get a fresh checkout and run
`ninja check-lldb` you'll observe the failure as it's not tracking
the dependency correctly. This fixes the problem on my machine,
and probably everywhere else.
llvm-svn: 326919
Summary:
- Complete element type of PDBSymbolTypeArray.
- Add a test to check types of multi-dimensional array and pointers with CVR.
Reviewers: zturner, rnk, lldb-commits
Reviewed By: zturner
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D44167
llvm-svn: 326859
Summary:
The test was failing in remote debugging scenario with windows as a host
as cmd.exe is not able to parse the complicated shell commands in the
Makefile.
The test seemed like a perfect candidate for a more focused testing
approach, so I have rewritten in on top of lldb-test's module-sections
functionality. The slight gotcha there was that the
Module::GetSectionList does not include the sections from the symbol
file until someone manually calls Module::GetSymbolVendor. Normally,
this is not an issue, because someone will have initialized the symbol
vendor by the time anyone starts looking at the sections. However, when
all one this is dump the section list, we run into this problem.
I've tried making this behavior more automatic, but it turns out it's
not that easy, so for now, I just manually initialize the Symbol Vendor
before dumping out the sections in lldb-test.
Reviewers: jankratochvil
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D42914
llvm-svn: 326805
Summary:
The command takes two input arguments: a module to use as a debug target
and a file containing a list of commands. The command will execute each
of the breakpoint commands in the file and dump the breakpoint state
after each one.
The commands are expected to be breakpoint set/remove/etc. commands, but
I explicitly allow any lldb command here, so you can do things like
change setting which impact breakpoint resolution, etc. There is also a
"-persistent" flag, which causes lldb-test to *not* automatically clear
the breakpoint list after each command. Right now I don't use it, but
the idea behind it was that it could be used to test more complex
combinations of breakpoint commands (set+modify, set+disable, etc.).
Right now the command prints out only the basic breakpoint state, but
more information can be easily added there. To enable easy matching of
the "at least one breakpoint location found" state, the command
explicitly prints out the string "At least one breakpoint location.".
To enable testing of breakpoints set with an absolute paths, I add the
ability to perform rudimentary substitutions on the commands: right now
the string %p is replaced by the directory which contains the command
file (so, under normal circumstances, this will perform the same
substitution as lit would do for %p).
I use this command to rewrite the TestBreakpointCaseSensitivity test --
the test was checking about a dozen breakpoint commands, but it was
launching a new process for each one, so it took about 90 seconds to
run. The new test takes about 0.3 seconds for me, which is approximately
a 300x speedup.
Reviewers: davide, zturner, jingham
Subscribers: luporl, lldb-commits
Differential Revision: https://reviews.llvm.org/D43686
llvm-svn: 326112
This test is consistently reporting unexpected pass for me, and the
expectedFailure decorator was removed from the legacy test in r310626.
Apply the same change to the lit version of this test.
Will investigate further if this fails once the new buildbot is running
tests.
llvm.org/pr17807
llvm-svn: 325856
Also, fix a missing dependency, as lit requires llvm-config
to run. This is becoming more and more important as we
write more FileCheck style tests.
Differential Revision: https://reviews.llvm.org/D43591
llvm-svn: 325719
Summary:
This is modeled after the clang and llvm lit tests.
Several properties have CMAKE_CFG_INTDIR as part of the path - this works correctly when the cmake generator only supports one configuration which is known at configuration time, but it does not work correctly when the cmake generator supports multiple configurations (for example, VS).
For VS, CMAKE_CFG_INTDIR ends up set as $Configuration and then it is never updated correctly. Instead, the lit configuration can use a property that can be overwritten at run time. AddLLVM does that for several properties (such as LLVM_TOOLS_DIR).
This change is also removing properties from the lit/CMakeLists.txt that are actually set during the call to configure_lit_site_cfg
Reviewers: zturner, lldb-commits
Reviewed By: zturner
Subscribers: llvm-commits, labath, stella.stamenova, mgorny, hintonda
Differential Revision: https://reviews.llvm.org/D43096
llvm-svn: 325652
Before this patch, LLDB was not able to evaluate expressions that
resulted in a value with a typeof- or decltype-type. This patch fixes
that.
Before:
(lldb) p int i; __typeof__(i) j = 1; j
(typeof (i)) $0 =
After:
(lldb) p int i; __typeof__(i) j = 1; j
(typeof (i)) $0 = 1
Differential revision: https://reviews.llvm.org/D43471
rdar://37461520
llvm-svn: 325568
Summary:
This is combination of following changes,
- Resolve function symbols in PDB symbol file. `lldb-test symbols` will display information about function symbols.
- Implement SymbolFilePDB::FindFunctions methods. On lldb console, searching function symbol by name and by regular expression are both available.
- Create lldb type for PDBSymbolFunc.
- Add tests to check whether functions with the same name but from different sources can be resolved correctly.
Reviewers: zturner, lldb-commits
Reviewed By: zturner
Subscribers: amccarth, labath, llvm-commits
Differential Revision: https://reviews.llvm.org/D42443
llvm-svn: 324707
Summary:
- Fix a null array access bug. This happens when creating the lldb type for a function that has no argument.
- Implement SymbolFilePDB::ParseTypes method. Using `lldb-test symbols` will show all supported types in the target.
- Create lldb types for variadic function, PDBSymbolTypePointer, PDBSymbolTypeBuiltin
- The underlying builtin type for PDBSymbolTypeEnum is always `Int`, correct it with the very first enumerator's encoding if any. This is more accurate when the underlying type is not signed or another integer type.
- Fix a bug when the compiler type is not created based on PDB_BuiltinType. For example, basic type `long` is of same width as `int` in a 32-bit target, and the compiler type of former one will be represented by the one generated for latter if using the default method. Introduce a static function GetBuiltinTypeForPDBEncodingAndBitSize to correct this issue.
- Basic type `long double` and `double` have the same bit size in MSVC and there is no information in a PDB to distinguish them. The compiler type of the former one is represented by the latter's.
- There is no line information about typedef, enum etc in a PDB and the source and line information for them are not shown.
- There is no information about scoped enumeration. The compiler type is represented as an unscoped one.
Reviewers: zturner, lldb-commits
Reviewed By: zturner
Subscribers: majnemer, llvm-commits
Differential Revision: https://reviews.llvm.org/D42434
llvm-svn: 323255
Summary:
- Fix a null array access bug. This happens when creating the lldb type for a function that has no argument.
- Implement SymbolFilePDB::ParseTypes method. Using `lldb-test symbols` will show all supported types in the target.
- Create lldb types for variadic function, PDBSymbolTypePointer, PDBSymbolTypeBuiltin
- The underlying builtin type for PDBSymbolTypeEnum is always `Int`, correct it with the very first enumerator's encoding if any. This is more accurate when the underlying type is not signed or another integer type.
- Fix a bug when the compiler type is not created based on PDB_BuiltinType. For example, basic type `long` is of same width as `int` in a 32-bit target, and the compiler type of former one will be represented by the one generated for latter if using the default method. Introduce a static function GetBuiltinTypeForPDBEncodingAndBitSize to correct this issue.
- Basic type `long double` and `double` have the same bit size in MSVC and there is no information in a PDB to distinguish them. The compiler type of the former one is represented by the latter's.
- There is no line informaton about typedef, enum etc in a PDB and the source and line information for them are not shown.
- There is no information about scoped enumeration. The compiler type is represented as an unscoped one.
Reviewers: zturner, lldb-commits, davide, asmith
Reviewed By: zturner, asmith
Subscribers: llvm-commits, davide
Differential Revision: https://reviews.llvm.org/D41427
llvm-svn: 322995
Summary:
This commit is a combination of the following changes:
- Cache PDB's global scope (executable) in SymbolFilePDB
- Change naming of `cu` to `compiland` which is PDB specific
- Change ParseCompileUnitForSymIndex to ParseCompileUnitForUID.
Prefer using a common name `UID` instead of PDB's `System Index`
Adding one more argument `index` to this method, which is used to
specify the index of the compile unit in a cached compile unit array
- Add GetPDBCompilandByUID method to simply code
- Fix a bug in getting the source file name for a PDB compiland.
For some reason, PDBSymbolCompiland::getSourceFileName() could
return an empty name, so if that is true, we have to walk through all
source files of this compiland and determine the right source file
used to generate this compiland based on language indicated.
The previous implementation called PDBSession::findOneSourceFile
method to get its name for the compiland. This is not accurate since
the `one source file` found could be a header other than source file.
Reviewers: zturner, lldb-commits
Reviewed By: zturner
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D41428
llvm-svn: 322433
The HAVE_LIBZ variable is not exported by LLVM, and therefore is not
available in stand-alone builds of other tools. Use LLVM_ENABLE_ZLIB
which is the name under which the effective value is exported.
Additional, use llvm_canonicalize_cmake_booleans() to make sure that
a correct (Python-safe) boolean value is passed down to lit.
Differential Revision: https://reviews.llvm.org/D41725
llvm-svn: 322081
Use full PATH when looking up test tools rather than just llvm tools
directory. r320813 has added a lookup for 'lldb-test' which is part
of LLDB tools rather than LLVM, and therefore is not present
in llvm_tools_dir before LLDB is installed.
While technically we could introduce separate per-directory lookup
logic, there is no real reason not to use the PATH formed earlier here,
and this is what other tools are doing.
Differential Revision: https://reviews.llvm.org/D41726
llvm-svn: 321932
Summary:
We use the llvm decompressor to decompress SHF_COMPRESSED sections. This enables
us to read data from debug info sections, which are sometimes compressed,
particuarly in the split-dwarf case. This functionality is only available if
llvm is compiled with zlib support.
Reviewers: clayborg, zturner
Subscribers: emaste, mgorny, aprantl, lldb-commits
Differential Revision: https://reviews.llvm.org/D40616
llvm-svn: 320813
Summary:
Using the in-tree clang should be the default test configuration as that
is the one compiler that we can be sure everyone has (better
reproducibility of test results). Also, it should hopefully reduce the
impact of pr35040.
This also reduces the number of settings which control the compiler
used. LLDB_TEST_C_COMPILER is used for C files and
LLDB_TEST_CXX_COMPILER for C++ files. Both of the settings default to
the in-tree clang.
Reviewers: zturner
Subscribers: mgorny, davide, lldb-commits
Differential Revision: https://reviews.llvm.org/D39215
llvm-svn: 316728
This is a resubmission of r313270. It broke standalone builds of
compiler-rt because we were not correctly generating the llvm-lit
script in the standalone build directory.
The fixes incorporated here attempt to find llvm/utils/llvm-lit
from the source tree returned by llvm-config. If present, it
will generate llvm-lit into the output directory. Regardless,
the user can specify -DLLVM_EXTERNAL_LIT to point to a specific
lit.py on their file system. This supports the use case of
someone installing lit via a package manager. If it cannot find
a source tree, and -DLLVM_EXTERNAL_LIT is either unspecified or
invalid, then we print a warning that tests will not be able
to run.
Differential Revision: https://reviews.llvm.org/D37756
llvm-svn: 313407
This patch is still breaking several multi-stage compiler-rt bots.
I already know what the fix is, but I want to get the bots green
for now and then try re-applying in the morning.
llvm-svn: 313335
This patch simplifies LLVM's lit infrastructure by enforcing an ordering
that a site config is always run before a source-tree config.
A significant amount of the complexity from lit config files arises from
the fact that inside of a source-tree config file, we don't yet know if
the site config has been run. However it is *always* required to run
a site config first, because it passes various variables down through
CMake that the main config depends on. As a result, every config
file has to do a bunch of magic to try to reverse-engineer the location
of the site config file if they detect (heuristically) that the site
config file has not yet been run.
This patch solves the problem by emitting a mapping from source tree
config file to binary tree site config file in llvm-lit.py. Then, during
discovery when we find a config file, we check to see if we have a
target mapping for it, and if so we use that instead.
This mechanism is generic enough that it does not affect external users
of lit. They will just not have a config mapping defined, and everything
will work as normal.
On the other hand, for us it allows us to make many simplifications:
* We are guaranteed that a site config will be executed first
* Inside of a main config, we no longer have to assume that attributes
might not be present and use getattr everywhere.
* We no longer have to pass parameters such as --param llvm_site_config=<path>
on the command line.
* It is future-proof, meaning you don't have to edit llvm-lit.in to add
support for new projects.
* All of the duplicated logic of trying various fallback mechanisms of
finding a site config from the main config are now gone.
One potentially noteworthy thing that was required to implement this
change is that whereas the ninja check targets previously used the first
method to spawn lit, they now use the second. In particular, you can no
longer run lit.py against the source tree while specifying the various
`foo_site_config=<path>` parameters. Instead, you need to run
llvm-lit.py.
Differential Revision: https://reviews.llvm.org/D37756
llvm-svn: 313270
Summary:
The capture() function was removed in r306625. This should fix PGO breakages
reported by Michael Zolotukhin.
Reviewers: mzolotukhin
Subscribers: sanjoy, llvm-commits
Differential Revision: https://reviews.llvm.org/D35088
llvm-svn: 307320
Use both LLDB- and LLVM-specific tool/library directories when LLDB is
being built stand-alone. This ensures that the freshly-built tools
(and libraries) are used correctly.
Without this patch, the test suite uses LLVM_TOOLS_DIR and LLVM_LIBS_DIR
to locate lldb, and set PATH and LD_LIBRARY_PATH. When doing
a stand-alone build, these variables represent the installed LLVM.
As a result, tests either fail due to missing lldb executable
or use an earlier installed LLDB version rather than the one being
built.
To solve this, additional LLDB_TOOLS_DIR and LLDB_LIBS_DIR variables
are added and populated using LLVM_*_OUTPUT_INTDIR. Those variables
contain directories used to output built executables and libraries.
In stand-alone builds, they represent the build-tree directories
used by LLDB. In integrated builds, they have the same values as
LLVM_*_DIR and therefore using them does not harm.
The new variables are prepended to PATH and LD_LIBRARY_PATH to ensure
that freshly built binaries are preferred over potentially earlier
installed ones. Furthermore, paths used to locate various tools are
updated to match appropriate locations.
Differential Revision: https://reviews.llvm.org/D29985
llvm-svn: 295621
On Linux, there is no "debugserver" process, and the RUN-line substitution will
fail if you try to substitute '%debugserver' with None.
Fixes PR30492.
llvm-svn: 283520
Summary:
This patch supplies basic infrastructure for LLDB to use LIT, and ports a few basic test cases from the LLDB test suite into LIT.
With this patch the LLDB lit system is not capable or intended to fully replace the existing LLDB test suite, but this first patch enables people to write lit tests for LLDB.
The lit substitution for %cc and %cxx default to the host compiler unless the CMake option LLDB_TEST_CLANG is On, in which case the in-tree clang will be used.
The target check-lldb-lit will run all lit tests including the lit-based executor for the unit tests. Alternatively there is a target generated for each subdirectory under the lit directory, so check-lldb-unit and check-lldb-expr will run just the tests under their respective directories.
The ported tests are not removed from the existing suite, and should not be until such a time when the lit runner is mature and in use by bots and workflows.
Reviewers: zturner, labath, jingham, tfiala
Subscribers: beanz, mgorny, lldb-commits
Differential Revision: https://reviews.llvm.org/D24591
llvm-svn: 281651
At the moment almost every lit.site.cfg.in contains two lines comment:
## Autogenerated by LLVM/Clang configuration.
# Do not edit!
The patch adds variable LIT_SITE_CFG_IN_HEADER, that is replaced from
configure_lit_site_cfg with the note and some useful information.
llvm-svn: 266522
If you have two folders with the same name but different cases,
MSBuild gets confused and generates an error when building
from within Visual Studio.
This patch renames it so that the cases of all folders named
"LLDB tests" match.
Patch by Jonathan Meier
Differential Revision: http://reviews.llvm.org/D16150
llvm-svn: 257684
Zachary Turner