The run command is only an abbreviation for the more verbose process
launch -- <args> but it works just as with GDB and therefore should be
mentioned in the GDB to LLDB command map.
For educational purposes I've not listed it as the first option on the
LLDB side so that new LLDB user can, if they want, also know what the
"native" way is for LLDB.
Here's the help documentation for the run command in lldb which gives
proof:
> (lldb) help run
> Launch the executable in the debugger.
>
> Syntax: run [<run-args>]
>
> Command Options Usage:
> run [<run-args>]
>
> 'run' is an abbreviation for 'process launch -c /bin/sh --'
Patch by: Konrad Kleine
Differential revision: https://reviews.llvm.org/D61483
llvm-svn: 360269
Summary:
The logic for translating a user_id into a DWARFDIE was replicated in
several places. This removes that redundancy and settles on a single
implementation in SymbolFileDWARF.
The reason for choosing that instead of DIERef was that we were
always immediately converting the returned DIERef into a DWARFDIE
anyway, which meant that one had to specify the SymbolFileDWARF argument
twice (once to get the DIERef, and once to get the actual DIE). Also,
passing a higher-level object (SymbolFileDWARF) into a lower-level one
(DIERef) seemed like a less intuitive arrangement than doing things the
other way around.
Reviewers: JDevlieghere, clayborg, aprantl
Subscribers: tberghammer, jankratochvil, lldb-commits
Differential Revision: https://reviews.llvm.org/D61648
llvm-svn: 360246
This patch fixes two incorrect headings in source.rst which caused it to
show up on the homepage. I also updated the titles to have more sensible
links there.
llvm-svn: 360219
This patch ensures that we propagate errors coming from the lldbinit
file trough the command/script interpreter. Before, if you did something
like command script import syntax_error.py, and the python file
contained a syntax error, lldb wouldn't tell you about it. This changes
with the current patch: errors are now propagated by default.
PS: Jim authored this change and I added testing.
Differential revision: https://reviews.llvm.org/D61579
llvm-svn: 360216
lldbExpression was linking against lldbPluginExpressionParserClang, and
lldbPluginExpressionParserClang was linking against lldbExpression.
There's no reason lldbExpression should need anything from
lldbPluginExpressionParserClang, so let's remove that dependency.
llvm-svn: 360208
This patch adds a command line flag that allows lldb to load local
lldbinit files.
Differential revision: https://reviews.llvm.org/D61578
llvm-svn: 360172
Remove SymbolVendorMacOSX from the test, as this plugin is not available
on non-mac platforms, and it does not seem to be necessary anyway.
Declare inlined-functions.yaml as an input of the test in cmake.
llvm-svn: 360169
Summary:
This is necessary to support parsing expressions like ".cfa -16 + ^", as
that format is used in breakpad STACK CFI expressions.
Since the PDB expressions use the same parser, this change will affect
them too, but I don't believe that should be a problem in practice. If
PDBs do contain the negative values, it's very likely that they are
intended to be parsed the same way, and if they don't, then it doesn't
matter.
In case that we do ever need to handle this differently, we can always
make the parser behavior customizable, or just use a different parser.
To make sure that the integer size is big enough for everyone, I switch
from using a (unsigned) 32-bit integer to a 64-bit (signed) one.
Reviewers: amccarth, clayborg, aleksandr.urakov
Subscribers: markmentovai, lldb-commits
Differential Revision: https://reviews.llvm.org/D61311
llvm-svn: 360166
Summary:
This behavior is specified in the Section 6.4.2.3 (Register Rule
instructions) of the DWARF4 spec. We were not doing that, which meant
that any register rule which was relying on the cfa value being there
was not evaluated correctly (it was aborted due to "out of bounds"
access).
I'm not sure how come this wasn't noticed before, but I guess this has
something to do with the fact that dwarf unwind expressions are not used
very often, and when they are, the situation is so complicated that the
CFA is of no use. I noticed this when I started emitting dwarf
expressions for the unwind information present in breakpad symbol files.
Reviewers: jasonmolenda, clayborg
Subscribers: aprantl, lldb-commits
Differential Revision: https://reviews.llvm.org/D61018
llvm-svn: 360158
Fix Register tests to reference memory access to arrays via %0 and %1,
rather than via referencing %rax and %rbx directly. This fixes test
build failures on 32-bit x86.
llvm-svn: 360148
Summary:
r360109 added a new enum case, causing lldb build to fail with several errors like:
lldb/source/Symbol/ClangASTContext.cpp:4342:11: error: enumeration value 'MacroQualified' not handled in switch [-Werror,-Wswitch]
switch (qual_type->getTypeClass()) {
^
This adds the missing switch cases.
I'm not an lldb maintainer and just used my best judgement that it's probably expected that we break in these cases. Feel free to ping / revert / fix this change if this behavior is not appropriate.
Reviewers: gribozavr
Reviewed By: gribozavr
Differential Revision: https://reviews.llvm.org/D61640
llvm-svn: 360146
The CPlusPlus Language plugin is unused in lldbBreakpoint. We should just remove
it.
A great follow up to this change would be to remove the dependency on the ObjC
language plugin, but that is actually used and requires some refactoring.
llvm-svn: 360105
Currently we have special handling for local lldbinit files in the
driver. At the same time, we have an SB API named
`SourceInitFileInCurrentWorkingDirectory` that does the same thing.
This patch removes the special handling from the driver and uses the API
instead. In addition to the obvious advantages of having one canonical
way of doing things and removing code duplication, this change also
means that the code path is the same for global and local lldb init
files.
Differential revision: https://reviews.llvm.org/D61577
llvm-svn: 360077
Checking this in for Antonio Afonso:
This diff changes the function LineEntry::GetSameLineContiguousAddressRange so that it also includes function calls that were inlined at the same line of code.
My motivation is to decrease the step over time of lines that heavly rely on inlined functions. I have multiple examples in the code base I work that makes a step over stop 20 or mote times internally. This can easly had up to step overs that take >500ms which I was able to lower to 25ms with this new strategy.
The reason the current code is not extending the address range beyond an inlined function is because when we resolve the symbol at the next address of the line entry we will get the entry line corresponding to where the original code for the inline function lives, making us barely extend the range. This then will end up on a step over having to stop multiple times everytime there's an inlined function.
To check if the range is an inlined function at that line I also get the block associated with the next address and check if there is a parent block with a call site at the line we're trying to extend.
To check this I created a new function in Block called GetContainingInlinedBlockWithCallSite that does exactly that. I also added a new function to Declaration for convinence of checking file/line named CompareFileAndLine.
To avoid potential issues when extending an address range I added an Extend function that extends the range by the AddressRange given as an argument. This function returns true to indicate sucess when the rage was agumented, false otherwise (e.g.: the ranges are not connected). The reason I do is to make sure that we're not just blindly extending complete_line_range by whatever GetByteSize() we got. If for some reason the ranges are not connected or overlap, or even 0, this could be an issue.
I also added a unit tests for this change and include the instructions on the test itself on how to generate the yaml file I use for testing.
Differential Revision: https://reviews.llvm.org/D61292
llvm-svn: 360071
The debug server does not need to use the instruction emulation. This
helps reduce the size of the final lldb-server binary by another ~100K
(~1% savings).
llvm-svn: 360067
Replace the constants used for r8/mm/xmm/ymm/zmm tests with something
more readable to ease debugging in case of failures (0x00 0x01 ...).
While at it, put the constants in array and copy them from memory
to simplify inline asm.
The original constants grew out of necessity. The xmm constants were
'weird' because they were intended to be different from mm constants
(as that was necessary to catch NetBSD implementation bug). The ymm
constants were made even weirded to not even partially collide with
other xmm registers (not saying it made sense, just how it was done).
Then, zmm constants were once again designed to avoid accidental
collisions with xmm and ymm constants, and at the same the 16 extra
registers required even more shuffling.
The new constants are meant to be more user-readable, so that a mistake
could be easily spotted. All of xmm, ymm and zmm tests use a sequence
of {0x00 0x01 0x02 ...}, shifted by 1 for every register. This should
provide enough uniquity, and space for future increase in number of
registers. Since mm and r8..r15 are printed as uint64_t rather than
byte-by-byte, they use 0x000102... As a result, on x86 endianness takes
care of making mm different than xmm.
The use of arrays is something I had to learn for zmm write tests. It
avoids having to specify all the input values separately, and makes
GCC happy about zmm-read test (it was rejected previously because of
hitting a limit of 30 constraints).
llvm-svn: 360041
These two methods are very similar and various refactorizations need to modify
both similar ways.
One could also just remove GetCompileUnitAtOffset and make
GetCompileUnitContainingDIEOffset to also accept offset of the CU itself
(currently it accepts only DIE offsets after the CU header).
But that would be less safe regarding some internal sanity checking.
Further code refactorization has been suggested by Pavel Labath.
Differential Revision: https://reviews.llvm.org/D61498
llvm-svn: 360038
This caused Clang to start erroring on the following:
struct S {
template <typename = int> explicit S();
};
struct T : S {};
struct U : T {
U();
};
U::U() {}
$ clang -c /tmp/x.cc
/tmp/x.cc:10:4: error: call to implicitly-deleted default constructor of 'T'
U::U() {}
^
/tmp/x.cc:5:12: note: default constructor of 'T' is implicitly deleted
because base class 'S' has no default constructor
struct T : S {};
^
1 error generated.
See discussion on the cfe-commits email thread.
This also reverts the follow-ups r359966 and r359968.
> this patch adds support for the explicit bool specifier.
>
> Changes:
> - The parsing for the explicit(bool) specifier was added in ParseDecl.cpp.
> - The storage of the explicit specifier was changed. the explicit specifier was stored as a boolean value in the FunctionDeclBitfields and in the DeclSpec class. now it is stored as a PointerIntPair<Expr*, 2> with a flag and a potential expression in CXXConstructorDecl, CXXDeductionGuideDecl, CXXConversionDecl and in the DeclSpec class.
> - Following the AST change, Serialization, ASTMatchers, ASTComparator and ASTPrinter were adapted.
> - Template instantiation was adapted to instantiate the potential expressions of the explicit(bool) specifier When instantiating their associated declaration.
> - The Add*Candidate functions were adapted, they now take a Boolean indicating if the context allowing explicit constructor or conversion function and this boolean is used to remove invalid overloads that required template instantiation to be detected.
> - Test for Semantic and Serialization were added.
>
> This patch is not yet complete. I still need to check that interaction with CTAD and deduction guides is correct. and add more tests for AST operations. But I wanted first feedback.
> Perhaps this patch should be spited in smaller patches, but making each patch testable as a standalone may be tricky.
>
> Patch by Tyker
>
> Differential Revision: https://reviews.llvm.org/D60934
llvm-svn: 360024
Summary:
The implementation of GetID used a relatively complicated algorithm,
which returned some kind of an offset of the unit in some file
(depending on the debug info flavour). The only thing this ID was used
for was to enable subseqent retrieval of the unit from the SymbolFile.
This can be made simpler if we just make the "ID" of the unit an index
into the list of the units belonging to the symbol file. We already
support indexed access to the units, so each unit already has a well
"index" -- this just makes it accessible from within the unit.
To make the distincion between "id" and "offset" clearer (and help catch
any misuses), I also rename DWARFDebugInfo::GetCompileUnit (which
accesses by offset) into DWARFDebugInfo::GetCompileUnitAtOffset.
On its own, this only brings a minor simplification, but it enables
further simplifications in the DIERef class (coming in a follow-up
patch).
Reviewers: JDevlieghere, clayborg, aprantl
Subscribers: arphaman, jdoerfert, lldb-commits, tberghammer, jankratochvil
Differential Revision: https://reviews.llvm.org/D61481
llvm-svn: 360014
This particular test fails once every so many runs on GreenDragon. Given
that the randomness in the inferior isn't critical to the test, I
removed it in the hopes that it is the cause of the flakiness.
llvm-svn: 359992
Use output constraints for specific general-purpose registers in order
to simplify the tests. They save us from having to manually put
the values in correct registers, and reduce the number of registers
needed as a result.
llvm-svn: 359978
This was added to support FreeBSD. The inclusion of this header increases the
size of `lldb-server` due to MCJIT being forcefully preserved. Conditionalise
the inclusion to shared builds of LLVM which will allow for MCJIT to be stripped
if unnecessary when performing static linking of tools. This shaves off ~28% of
the binary size for lldb-server when linked with gold using
`-ffunction-sections` and `-fdata-sections`.
llvm-svn: 359944
Ran clang-format on the added test file and use the new StringRef
comparison over the temporary ConstStrings. Also aligned the
end of one of the code string literals.
llvm-svn: 359931
Before this change the test would always pass if the path to the test
contained the number 11 in it. Thanks to Ted for pointing this out.
llvm-svn: 359930
This patch makes `re` an alias for `register`. Currently `re<TAB>` gives
you the choice between `register` and `reproducer`. Given that you use
`register` a lot more often, it should win for the common substring.
Differential revision: https://reviews.llvm.org/D61469
llvm-svn: 359927
We don't need the variables in lit, we can use the capabilities to check
if the utility exists.
Differential revision: https://reviews.llvm.org/D61533
llvm-svn: 359926
Summary:
In an Objective-C context a local variable and namespace can cause an ambiguous name lookup when used in an expression. The solution involves mimicking the existing C++ solution which is to add local using declarations for local variables. This causes a different type of lookup to be used which eliminates the namespace during acceptable results filtering.
Differential Revision: https://reviews.llvm.org/D59960
llvm-svn: 359921
Summary:
According to [C128] "Virtual functions should specify exactly one
of `virtual`, `override`, or `final`", I've added override where a
virtual function is overriden but the explicit `override` keyword
was missing. Whenever both `virtual` and `override` were specified,
I removed `virtual`. As C.128 puts it:
> [...] writing more than one of these three is both redundant and
> a potential source of errors.
I anticipate a discussion about whether or not to add `override` to
destructors but I went for it because of an example in [ISOCPP1000].
Let me repeat the comment for you here:
Consider this code:
```
struct Base {
virtual ~Base(){}
};
struct SubClass : Base {
~SubClass() {
std::cout << "It works!\n";
}
};
int main() {
std::unique_ptr<Base> ptr = std::make_unique<SubClass>();
}
```
If for some odd reason somebody removes the `virtual` keyword from the
`Base` struct, the code will no longer print `It works!`. So adding
`override` to destructors actively protects us from accidentally
breaking our code at runtime.
[C128]: https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md#c128-virtual-functions-should-specify-exactly-one-of-virtual-override-or-final
[ISOCPP1000]: https://github.com/isocpp/CppCoreGuidelines/issues/1000#issuecomment-476951555
Reviewers: teemperor, JDevlieghere, davide, shafik
Reviewed By: teemperor
Subscribers: kwk, arphaman, kadircet, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D61440
llvm-svn: 359868
The part which checks whether vla_expr shows up in the variable list
does not pass on non-darwin platforms. Add the appropriate decorator.
llvm-svn: 359867
logging messages that are written the same, making it difficult to
know for certain which code path was taken based on a logfile. Add
some words to make each unique.
Right now the ordering for finding a FullUnwindPlan (ignoring
fallback unwind plan logic) is
1. If this is a _sigtramp like function, try eh_frame which is
hand written on darwin systems to account for finding the
saved register context correctly.
2. Ask the DynamicLoader if eh_frame should be preferred for
this frame. Some binaries on the system may have hand-written
eh_frame and the DynamicLoader is the source for this. (primarily
this is for hand-written assembly in the objc runtime, and we tell
lldb to trust that for functions in libobjc.dylib.)
3. if 0th frame, use GetUnwindPlanAtNonCallSite plan.
4. GetUnwindPlanAtCallSite {for 0th or any other}
5. GetUnwindPlanAtNonCallSite {now for non-0th frames, only if not from a compiler? hm.}
6. GetUnwindPlanArchitectureDefaultAtFunctionEntry if we're on the first instruction
7. Architectural default unwind plan ABI::CreateDefaultUnwindPlan
I'm moving #6 -- DefaultAtFunctionEntry -- up to between #3 and #4,
where we're already doing things specific to the zeroth frame. If
we're on the zeroth frame and the GetUnwindPlanAtNonCallSite plan
has failed for some reason, and we're on the first instruction, we
should definitely use DefaultAtFunctionEntry instead of any other
unwind plan. If we're trying to step out of some rando function
on the system that we couldn't assembly instruction inspect, this
is sufficient for us to step out of it.
llvm-svn: 359847
lldb has an expression that runs in the inferior process to collect
the isa values and hash of the class names for classes in the
system's shared cache. In recent OSes, swift classes are in this
table and the function the jitted expression calls returns demangled
names. We need to compute the hashes based on the mangled names.
So for these names, return a hash value of 0 which indicates that
lldb should read the class name directly out of the runtime tables
and compute the hash itself.
When this patch is absent, the lldb+swift testsuite has many failures
on a recent macOS system; there isn't a direct non-swift way to
test for this being correct.
<rdar://problem/47935062>
llvm-svn: 359843
by respecting the "artificial" attribute on variables. Function
arguments that are artificial and useful to end-users are being
whitelisted by the language runtime.
<rdar://problem/45322477>
Differential Revision: https://reviews.llvm.org/D61451
llvm-svn: 359841
The debug server does not need to use the instruction emulation. This helps
reduce the size of the final lldb-server binary by another ~100K (~1% savings).
llvm-svn: 359832
`_MSC_VER` indiciates that you are building with MSVC, not that you are building
for Windows. Use `_WIN32` (which identifies Win32 and Win64).
llvm-svn: 359817
Summary:
This check seems unnecessary as we already assert the same condition above and also access `sc.comp_unit`
before this check.
Reviewers: aprantl
Reviewed By: aprantl
Subscribers: jdoerfert, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D61394
llvm-svn: 359813
This restructures the initialization path to move the ObjectContainer
initialization into the *full* initialization path. This is not needed
for the lldb-server initialization path. This helps strip off ~1MiB
from the binary.
llvm-svn: 359810
Two tests cannot share the same name, because they will generate an
identical trace file. When that happens, this can lead to a race
condition where dotest fails when trying to move both files into the
trace directory, because the file has already been moved. Additionally,
the trace will have been overwritten by the test that finishes last.
llvm-svn: 359807
Since Darwin target implements support for zmm* registers without
matching support for the respectively added xmm* and ymm* registers,
split the tests for each register group. To reduce code duplication,
the tests are using the same source file (which sets more registers
than necessary but that should not cause any harm).
Differential Revision: https://reviews.llvm.org/D61376
llvm-svn: 359780
Summary:
I think there universal agreement that Minion isn't the best name for this class. This patch renames the class
to ASTImporterDelegate to better reflect it's goal of monitoring and extending the ASTImporter.
Reviewers: aprantl, shafik, martong, a.sidorin, davide
Reviewed By: aprantl, shafik, davide
Subscribers: rnkovacs, davide, abidh, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D61299
llvm-svn: 359777
Summary:
In r259902, LLDB started injecting all the locals in every expression
evaluation. This fixed a bunch of issues, but also caused others, mostly
performance regressions on some codebases. The regressions were bad
enough that we added a setting in r274783 to control the behavior and
we have been shipping with the setting off to avoid the perf regressions.
This patch changes the logic injecting the local variables to only inject
the ones present in the expression typed by the user. The approach is
fairly simple and just scans the typed expression for every local name.
Hopefully this gives us the best of both world as it just realizes the
types of the variables really used by the expression.
Landing this requires the 2 other issues I pointed out today to be addressed
but I wanted to gather comments right away.
Original patch by Frédéric Riss!
Reviewers: jingham, clayborg, friss, shafik
Reviewed By: jingham, clayborg
Subscribers: teemperor, labath, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D46551
llvm-svn: 359773
Address an ambiguity between lldb_private::Thread and
llvm::minidump::Thread. Follow-up to llvm r359762 (which introduced the
second type).
llvm-svn: 359765
You can only find out about this useful customization by browsing
the settings list output or the llvm.org web pages. Mention it
in the help for thread list, thread backtrace & _regex_bt commands
to make it more discoverable.
llvm-svn: 359752
This test is flaky on GreenDragon. Since it was a pexpect test and
straightforward enough to convert, I went ahead and converted it to a
lit test.
Differential revision: https://reviews.llvm.org/D61414
llvm-svn: 359751
This patch ensures that we honor the stop-command-source-on-error
setting from `command source`. The problem is that we didn't
differentiate between the boolean value being true or false, or not
being set. For the latter scenario, we should calculate the value in the
command interpreter based on the global options.
Differential revision: https://reviews.llvm.org/D61406
llvm-svn: 359750
Summary:
This will fix a bug where during expression parsing we are not setting a CXXRecordDecl to not be passed in registers and the resulting code generation is wrong.
The DWARF attribute DW_CC_pass_by_reference tells us that we should not be passing in registers i.e. RAA_Indirect.
This change depends this clang change which fixes the fact that the ASTImporter does not copy RecordDeclBits for CXXRecordDecl: https://reviews.llvm.org/D61140
Differential Revision: https://reviews.llvm.org/D61146
llvm-svn: 359732
After multiple attempts from both Fred and Adrian, this variant of the
test is still flaky on GreenDragon. This commit disables it while we
continue investigate.
llvm-svn: 359724
Fix bugs in piod_len return value processing in ReadMemory()
and WriteMemory() methods. In particular, add support for piod_len == 0
indicating EOF, and fix summing bytes_read/bytes_written when PT_IO does
partial reads/writes.
The EOF condition could happen if LLDB attempts to read past
vm.maxaddress, e.g. as a result of RBP containing large (invalid) value.
Previously, the 0 return caused the function to retry reading via PT_IO
indefinitely, effectively deadlooping lldb-server.
Partial reads probably did not occur in practice, yet they would cause
ReadMemory() to return incorrect bytes_read and/or overwrite previously
read data.
WriteMemory() suffered from analoguous problems.
Differential Revision: https://reviews.llvm.org/D61310
llvm-svn: 359572
Summary:
This node represents can be used to refer to the initial value, which is
sometimes pushed onto the DWARF stack as the "input" to the DWARF
expression. The typical use case (and the reason why I'm introducing it)
is that the "Canonical Frame Address" is passed this way to the DWARF
expressions computing the values of registers during frame unwind.
The nodes are converted into dwarf by keeping track of DWARF stack depth
an any given point, and then copying the initial value from the bottom
of the stack via the DW_OP_pick opcode. This could be made more
efficient for simple expressions, but here I chose to start with the
most general implementation possible.
Reviewers: amccarth, clayborg, aleksandr.urakov
Subscribers: aprantl, jasonmolenda, lldb-commits, markmentovai
Differential Revision: https://reviews.llvm.org/D61183
llvm-svn: 359560
Summary:
This patch is a follow-up for D58125. It implements the manual instantiation and merging of 'std' templates like
`std::vector` and `std::shared_ptr` with information from the debug info AST. This (finally) allows using these classes
in the expression evaluator like every other class (i.e. things like `vec.size()` and shared_ptr debugging now works, yay!).
The main logic is the `CxxModuleHandler` which intercept the ASTImporter import process and replaces any `std` decls
by decls from the C++ module. The decls from the C++ module are "imported" by just deserializing them directly in
the expression evaluation context. This is mostly because we don't want to rely on the ASTImporter to correctly import
these declarations, but in the future we should also move to the ASTImporter for that.
This patch doesn't contain the automatic desugaring for result variables. This means that if you call for example
`size` of `std::vector` you maybe get some very verbose typedef'd type as the variable type, e.g.
`std::vector<int, std::allocator<int>>::value_type`.
This is not only unreadable, it also means that our ASTImporter has to import all these types and associated
decls into the persisent variable context. This currently usually leads to some assertion getting triggered
in Clang when the ASTImporter either makes a mistake during importing or our debug info AST is inconsitent.
The current workaround I use in the tests is to just cast the result to it's actual type (e.g. `size_t` or `int`) to prevent
the ASTImporter from having to handle all these complicated decls.
The automatic desugaring will be a future patch because I'm not happy yet with the current code for that and because
I anticipate that this will be a controversial patch.
Reviewers: aprantl, shafik, jingham, martong, serge-sans-paille
Reviewed By: martong
Subscribers: balazske, rnkovacs, mgorny, mgrang, abidh, jdoerfert, lldb-commits
Tags: #c_modules_in_lldb, #lldb
Differential Revision: https://reviews.llvm.org/D59537
llvm-svn: 359538
Apparently setting the per-test-timeout and not having the psutil
package constitutes to a fatal error. So only set the timeout when the
module is available.
llvm-svn: 359503
The timeout wasn't working because it's a property of the lit
configuration, not of the configuration in lit.site.cfg. This sets the
property for the correct object.
llvm-svn: 359492
CMake specifies that the DEPENDS field of add_custom_target is for files
and output of add_custom_command. In order to add a target dependency,
add_dependencies should be used.
llvm-svn: 359490
GetSDKVersion expects the number of version fields not their byte size
and will happily overwrite later contents of the stack.
Differential Revision: https://reviews.llvm.org/D61218
llvm-svn: 359471
As discussed on the mailing list, we should be able to generate the
Python reference without building all of LLDB. To make that possible I
create a dummy python package, which is then parsed by epydoc. The
latter will complain that it couldn't import lldb, but that doesn't
matter as far as generation of the docs is concerned.
Differential revision: https://reviews.llvm.org/D61216
llvm-svn: 359465
Their functionality overlaps with the newly introduced
PostfixExpressionTests (r359288). Tests, which still exercise some
pdb-related functionality (register name resolution) have been kept.
llvm-svn: 359450
Summary:
libedit implementation of el_get(EL_GETTC) had a bug, where it was
consuming vararg arguments until reaching the first null pointer (and
not just two, as documented). This was causing (at least) errors to be
reported when running the tests under msan.
The issue has since been fixed in libedit, but this adds patch adds a
trivial workaround, so that we operate correctly with the libedit
versions which are already out there.
Reviewers: christos, krytarowski, davide
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D61191
llvm-svn: 359449
Introduce two initial tests for 'register write' command. The tests
first clobber x86 general purpose registers, then call int3 to let lldb
write to them, then print the new values. FileCheck takes care of
verifying whether correct values were written.
Differential Revision: https://reviews.llvm.org/D61221
llvm-svn: 359441
Introduce tests for reading the eight x86 general purpose registers,
i.e. RAX/RBX/RCX/RDX/RBP/RSP/RSI/RDI and their shorter counterparts.
The test comes in separate 32-bit and 64-bit variant, targeting
appropriate processors.
While technically the 32-bit test could run on amd64, it would be
redundant to the 64-bit version, so just run one of them on each arch.
Differential Revision: https://reviews.llvm.org/D61210
llvm-svn: 359438
Summary:
The DWARF spec states that the DWARF stack arguments are numbered from
the top. Our implementation of DW_OP_pick was counting them from the
bottom.
This bug probably wasn't noticed because nobody (except my upcoming
postfix-to-DWARF converter) uses DW_OP_pick, but I've cross-checked with
gdb to confirm that counting from the top is the expected behavior.
This patch fixes the implementation to match the spec and gdb behavior
and adds a test.
Reviewers: jasonmolenda, clayborg
Subscribers: mgorny, aprantl, lldb-commits
Differential Revision: https://reviews.llvm.org/D61182
llvm-svn: 359436
Summary:
Dump more information about "access violation" and "in page error" exceptions to
description. Description now contains data about read/write violation type and
actual address as described at
https://docs.microsoft.com/en-us/windows/desktop/api/winnt/ns-winnt-_exception_record
Reviewers: asmith, stella.stamenova
Reviewed By: stella.stamenova
Subscribers: teemperor, amccarth, abidh, lldb-commits, aleksandr.urakov
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D60519
llvm-svn: 359420
Summary:
As reported in LLVM bug 41487, the check in this function is wrong and should be
the same as the described check in the comment (which is correctly copied from the
ARM ISA reference).
Reviewers: #lldb, davide, JDevlieghere
Reviewed By: #lldb, davide, JDevlieghere
Subscribers: davide, javed.absar, kristof.beyls, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D60654
llvm-svn: 359387
In r359354 a GetDebugger() method was added to the CommandObject class,
so that we didn't have to go through the command interpreter to obtain
the script interpreter. This patch simplifies other call sites where
m_interpreter.GetDebugger() was used, and replaces them with a shorter
call to the new method.
llvm-svn: 359373
The FormatType enum and corresponding field are unused. This patch
removes the type, field and simplifies the macros that initialize them.
llvm-svn: 359372
Remove unused from the driver class. I noticed a bunch of small thing
while doing this that didn't warrant separate commits, so I've lumped
them together into this patch.
llvm-svn: 359355
This is part two of the change started in r359330. This patch moves the
ownership of the script interpreter from the command interpreter into
the debugger. I would've preferred to remove the lazy initialization,
however the fact that the scripting language is set after the debugger
is created makes that tricky. So for now this does exactly the same
thing as when it was under the command interpreter. The result is that
this patch is fully NFC.
Differential revision: https://reviews.llvm.org/D61211
llvm-svn: 359354
stop-hook-threads.cpp uses C++11 features, so ask for C++11 explicitely.
This isn't broken on mainstream because clang defaults to a newer C++
version now, but it breaks if testing against an older compiler.
llvm-svn: 359349
The script language argument was passed from the debugger to the command
interpreter, only to call SetScriptLanguage on the debugger again. It
wasn't even used to initialize the script interpreter, because that
would query the debugger again. This patch removes the needless back and
forth.
llvm-svn: 359346
As discussed in D61090, there's no good reason for the script
interpreter to depend on the command interpreter. When looking at the
code, it becomes clear that we mostly use the command interpreter as a
way to access the debugger. Hence, it makes more sense to just pass that
to the script interpreter directly.
This is part 1 out of 2. I have another patch in the pipeline that
changes the ownership of the script interpreter to the debugger as well,
but I didn't get around to finish that today.
Differential revision: https://reviews.llvm.org/D61172
llvm-svn: 359330
Add a new lit-cpuid tool that detects CPU features used by some of
the tests, and use it to populate available_features in lit. For now,
this means that the test for MM/XMM register read will be run only
when the host CPU support SSE instruction set. However, this is going
to make it possible to introduce additional tests relying on AVX.
Differential Revision: https://reviews.llvm.org/D61073
llvm-svn: 359303
Summary:
The new dwarf generator is pretty much a verbatim copy of the one in
PDB.
In order to write a pdb-independent test for it, I needed to write a
dummy "symbol resolver", which (together with the fact that I'll need
one more for breakpad-specific resolution logic) prompted me to create a
more simple interface for algorithms which replace or "resolve"
SymbolNodes. The resolving algorithms in NativePDB have been updated to
make use of that too.
I have removed a couple of NativePDB tests which weren't testing
anything pdb-specific and where the tested functionality was covered by
the new format-agnostic tests I have added.
Reviewers: amccarth, clayborg, aleksandr.urakov
Subscribers: aprantl, markmentovai, lldb-commits, jasonmolenda, JDevlieghere
Differential Revision: https://reviews.llvm.org/D61056
llvm-svn: 359288
Summary:
When we want to compare a ConstString against a string literal (or any other non-ConstString),
we currently have to explicitly turn the other string into a ConstString. This makes sense as
comparing ConstStrings against each other is only a fast pointer comparison.
However, currently we (rather incorrectly) use in several places in LLDB temporary ConstStrings when
we just want to compare a given ConstString against a hardcoded value, for example like this:
```
if (extension != ConstString(".oat") && extension != ConstString(".odex"))
```
Obviously this kind of defeats the point of ConstStrings. In the comparison above we would
construct two temporary ConstStrings every time we hit the given code. Constructing a
ConstString is relatively expensive: we need to go to the StringPool, take a read and possibly
an exclusive write-lock and then look up our temporary string in the string map of the pool.
So we do a lot of heavy work for essentially just comparing a <6 characters in two strings.
I initially wanted to just fix these issues by turning the temporary ConstString in static variables/
members, but that made the code much less readable. Instead I propose to add a new overload
for the ConstString comparison operator that takes a StringRef. This comparison operator directly
compares the ConstString content against the given StringRef without turning the StringRef into
a ConstString.
This means that the example above can look like this now:
```
if (extension != ".oat" && extension != ".odex")
```
It also no longer has to unlock/lock two locks and call multiple functions in other TUs for constructing
the temporary ConstString instances. Instead this should end up just being a direct string comparison
of the two given strings on most compilers.
This patch also directly updates all uses of temporary and short ConstStrings in LLDB to use this new
comparison operator. It also adds a some unit tests for the new and old comparison operator.
Reviewers: #lldb, JDevlieghere, espindola, amccarth
Reviewed By: JDevlieghere, amccarth
Subscribers: amccarth, clayborg, JDevlieghere, emaste, arichardson, MaskRay, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D60667
llvm-svn: 359281
Use constexpr to explicitly indicate that we're dealing with integer
constants, and provoke clang to assign them straight to registers
whenever possible. Adjust input constraints in %mmN tests to "rm"
as using integer constants is apparently disallowed there. Also
use "i" for %rN tests, as we don't want clang to accidentally clobber
those general purpose registers while assigning to them (however
unlikely that is).
llvm-svn: 359228
Add tests covering read operations for the general-purpose and XMM
registers added in x86_64 (r8-r15 and xmm8-xmm15).
Differential Revision: https://reviews.llvm.org/D61072
llvm-svn: 359210
Remove the use of 2-element array for XMM data. It is an accidental
leftover from previous implementation attempt, and it is unnecessary
with xmm_t.
Differential Revision: https://reviews.llvm.org/D61085
llvm-svn: 359208
Under very specific circumstances the default shell /bin/sh might
print stuff to stderr before launching lldb-argdumper, which then
confuses the JSON parser. This patch suppresses stderr output from
lldb-argdumper to avoid this situation.
rdar://problem/50149390
Differential Revision: https://reviews.llvm.org/D61101
llvm-svn: 359156
Summary:
When we encounter a templated function in the debug information, we
were creating an AST that looked like this:
FunctionTemplateDecl 0x12980ab90 <<invalid sloc>> <invalid sloc> foo<int>
|-TemplateTypeParmDecl 0x12980aad0 <<invalid sloc>> <invalid sloc> class depth 0 index 0 T
|-FunctionDecl 0x12980aa30 <<invalid sloc>> <invalid sloc> foo<int> 'int (int)' extern
| |-TemplateArgument type 'int'
| `-ParmVarDecl 0x12980a998 <<invalid sloc>> <invalid sloc> t1 'int'
`-FunctionDecl 0x12980aa30 <<invalid sloc>> <invalid sloc> foo<int> 'int (int)' extern
|-TemplateArgument type 'int'
`-ParmVarDecl 0x12980a998 <<invalid sloc>> <invalid sloc> t1 'int'
Note that the FunctionTemplateDecl has 2 children which are identical (as
in have the same address). This is not what Clang is doing:
FunctionTemplateDecl 0x7f89d206c6f8 </tmp/template.cpp:1:1, line:4:1> line:2:5 foo
|-TemplateTypeParmDecl 0x7f89d206c4a8 <line:1:10, col:19> col:19 referenced typename depth 0 index 0 T
|-FunctionDecl 0x7f89d206c660 <line:2:1, line:4:1> line:2:5 foo 'int (T)'
| `-ParmVarDecl 0x7f89d206c570 <col:9, col:11> col:11 t1 'T'
`-FunctionDecl 0x7f89d206cb60 <line:2:1, line:4:1> line:2:5 used foo 'int (int)'
|-TemplateArgument type 'int'
`-ParmVarDecl 0x7f89d206ca68 <col:9, col:11> col:11 t1 'int':'int'
The 2 chidlren are different and actually repesent different things: the first
one is the unspecialized version and the second one is specialized. (Just looking
at the names shows another major difference which is that we create the parent
with a name of "foo<int>" when it should be just "foo".)
The fact that we have those 2 identical children confuses the ClangImporter
and generates an infinite recursion (reported in https://llvm.org/pr41473).
We cannot create the unspecialized version as the debug information doesn't
contain a mapping from the template parameters to their use in the prototype.
This patch just creates 2 different FunctionDecls for those 2 children of the
FunctionTemplateDecl. This avoids the infinite recursion and allows us to
call functions. As the XFAILs in the added test show, we've still got issues
in our handling of templates. I believe they are mostly centered on the fact
that we create do not register "foo" as a template, but "foo<int>". This is
a bigger change that will need changes to the debug information generation.
I believe this change makes sense on its own.
Reviewers: shafik, clayborg, jingham
Subscribers: aprantl, javed.absar, kristof.beyls, lldb-commits
Differential Revision: https://reviews.llvm.org/D61044
llvm-svn: 359140
Summary:
This is needed for gcc/cstdlib++ 5.4.0, where __get_cpuid_count is not
defined in cpuid.h.
Reviewers: labath
Reviewed By: labath
Subscribers: lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D61036
llvm-svn: 359120
Summary:
This previous fix 5469bda296 did not have a test since we did not have a reproducer.
This is related to how formatters deal with pointers and references. The added tests both the new behavior and covers the previous bug fix as well.
Differential Revision: https://reviews.llvm.org/D60588
llvm-svn: 359118
Summary:
After the last round of cleanups, this script was almost a no-op. The
only piece of functionality that remained was the one which tried to
make the swig-generated function signatures more pythonic.
The "tried" part is important here, as it wasn't doing a really good job
and the end result was not valid python nor c (e.g.,
SetExecutable(SBAttachInfo self, str const * path)).
Doing these transformations another way is not possible, as these
signatures are generated by swig, and not present in source. However,
given that this is the only reason why we need a swig post-process step,
and that the current implementation is pretty sub-optimal, this patch
simply abandons the signature fixup idea, and chooses to simplify our
build process instead.
Reviewers: amccarth, jingham, clayborg
Subscribers: mgorny, lldb-commits
Differential Revision: https://reviews.llvm.org/D61000
llvm-svn: 359092
Summary:
The postfix expressions in PDB and breakpad symbol files are similar
enough that they can be parsed by the same parser. This patch
generalizes the parser in the NativePDB plugin and moves it into the
PostfixExpression file created in the previous commit (r358976).
The generalization consists of treating any unrecognised token as a
"symbol" node (previously these would only be created for tokens
starting with "$", and other token would abort the parse). This is
needed because breakpad symbols can also contain ".cfa" tokens, which
refer to the frame's CFA.
The cosmetic changes include:
- using a factory function instead of a class for creating nodes (this
is more generic as it allows the same BumpPtrAllocator to be used for
other things too)
- using dedicated function for parsing operator tokens instead of a
DenseMap (more efficient as we don't need to create the DenseMap every
time).
Reviewers: amccarth, clayborg, JDevlieghere, aleksandr.urakov
Subscribers: jasonmolenda, lldb-commits, markmentovai, mgorny
Differential Revision: https://reviews.llvm.org/D61003
llvm-svn: 359073
Jonas Devlieghere