This old test used a completely hand-rolled Makefile. Modernize so that
it's able to cross-compile. And XFAIL the test as it fails on embedded
targets...
llvm-svn: 374256
When building an executable and a shared library at the same time (yes,
Makefile.rules is setup to do this!) the executable was not codesigned.
llvm-svn: 374251
Summary: The PlaceholderObjectFile has an assert in SetLoadAddress that fires if "m_base == value" is not true. To avoid this, we create check that the base address matches, and if it doesn't we clear the module that was found using the UUID so that we create a new PlaceholderObjectFile. Added a test to cover this issue.
Reviewers: labath, aadsm, dvlahovski
Subscribers: lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D68106
llvm-svn: 374242
Summary:
It's really annoying and confusing to have to keep referring
back to earlier versions of this SBFile work to find the
tests that need to be added for each patch, and not duplicate
them with new tests.
This patch just imports all my tests. A bunch of them don't
work yet, so they are marked to be skipped. They'll be
unmarked as I fix them.
One of these tests will actually trip an assert in the SWIG
code now instead of just failing, so I'm fixing that here too.
Reviewers: JDevlieghere, jasonmolenda, labath
Reviewed By: JDevlieghere, labath
Subscribers: lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D68433
llvm-svn: 374237
Summary:
This patch adds SWIG typemaps that can convert arbitrary python
file objects into lldb_private::File.
A SBFile may be initialized from a python file using the
constructor. There are also alternate, tagged constructors
that allow python files to be borrowed, and for the caller
to control whether or not the python I/O methods will be
called even when a file descriptor is available.I
Reviewers: JDevlieghere, jasonmolenda, labath
Reviewed By: labath
Subscribers: zturner, amccarth, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D68188
llvm-svn: 374225
TestCPP11EnumTypes.py should have covered all our bases when it comes
to typed enums, but it missed the regression introduced in r374066.
The reason it didn't catch it is somewhat funny: the test was copied
over from another test that recompiled a source file with a different
base type every time, but neither the test source nor the python code
was adapted for testing enums. As a result, this test was just running
8 times the exact same checks on the exact same binary.
This commit fixes the coverage and addresses the issue revealed by
the new tests.
llvm-svn: 374108
Most of the secondary Makefiles we have are just a couple variable
definitions and then an include of Makefile.rules. This patch removes
most of the secondary Makefiles and replaces them with a direct
invocation of Makefile.rules in the main Makefile. The specificities
of each sub-build are listed right there on the recursive $(MAKE)
call. All the variables that matter are being passed automagically by
make as they have been passed on the command line. The only things you
need to specify are the variables customizating the Makefile.rules
logic for each image.
This patch also removes most of the clean logic from those Makefiles
and from Makefile.rules. The clean rule is not required anymore now
that we run the testsuite in a separate build directory that is wiped
with each run. The patch leaves a very crude version of clean in
Makefile.rules which removes everything inside of $(BUILDDIR). It does
this only when the $(BUILDDIR) looks like a sub-directory of our
standard testsuite build directory to be extra safe.
Reviewers: aprantl, labath
Subscribers: lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D68558
llvm-svn: 374076
Summary:
Using enumerators as flags is standard practice. This patch adds
support to LLDB to display such enum values symbolically, eg:
(E) e1 = A | B
If enumerators don't cover the whole value, the remaining bits are
displayed as hexadecimal:
(E) e4 = A | 0x10
Detecting whether an enum is used as a bitfield or not is
complicated. This patch implements a heuristic that assumes that such
enumerators will either have only 1 bit set or will be a combination
of previous values.
This patch doesn't change the way we currently display enums which the
above heuristic would not consider as bitfields.
Reviewers: jingham, labath
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D67520
llvm-svn: 374067
Summary:
TestLoadUsingPaths will fail if the build directory has
symlinks in its path, because the real paths reported by
the debugger won't match the symlink-laden paths it's expecting.
This can be solved just by using os.path.realpath on the base
path for the test.
Reviewers: JDevlieghere, jasonmolenda, labath
Reviewed By: JDevlieghere
Subscribers: lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D68618
llvm-svn: 374007
Summary:
dotest.py currently requires a filterspec to be of the
form `TestCase.test_method`. This patch makes it more
flexible, so you can pass `TestModule.TestCase.test_method`
or `TestModule.TestCase` or `TestCase.test_method` or just
`test_method`.
This makes it more convenient to just copy a test name
out of the terminal after running a bunch of tests and use
it as a filterspec.
Reviewers: JDevlieghere, jasonmolenda, labath
Reviewed By: JDevlieghere
Subscribers: jingham, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D68545
llvm-svn: 373997
Summary:
Someone wrote SetEffectiveSetEffectiveGroupID instead of SetEffectiveUserID.
After this fix, the android process list can show user names, e.g.
```
PID PARENT USER GROUP EFF USER EFF GROUP TRIPLE ARGUMENTS
====== ====== ========== ========== ========== ========== ============================== ============================
529 1 root 0 root 0 /sbin/ueventd
```
Reviewers: labath,clayborg,aadsm,xiaobai
Subscribers:
llvm-svn: 373953
Summary:
For context: https://reviews.llvm.org/D68293
We need a way to show all the processes on android regardless of the user id.
When you run `platform process list`, you only see the processes with the same user as the user that launched lldb-server. However, it's quite useful to see all the processes, though, and it will lay a foundation for full apk debugging support from lldb.
Before:
```
PID PARENT USER TRIPLE NAME
====== ====== ========== ======================== ============================
3234 1 aarch64-unknown-linux-android adbd
8034 3234 aarch64-unknown-linux-android sh
9096 3234 aarch64-unknown-linux-android sh
9098 9096 aarch64-unknown-linux-android lldb-server
(lldb) ^D
```
Now:
```
(lldb) platform process list -x
205 matching processes were found on "remote-android"
PID PARENT USER TRIPLE NAME
====== ====== ========== ======================== ============================
1 0 init
524 1 init
525 1 init
531 1 ueventd
568 1 logd
569 1 aarch64-unknown-linux-android servicemanager
570 1 aarch64-unknown-linux-android hwservicemanager
571 1 aarch64-unknown-linux-android vndservicemanager
577 1 aarch64-unknown-linux-android qseecomd
580 577 aarch64-unknown-linux-android qseecomd
...
23816 979 com.android.providers.calendar
24600 979 com.verizon.mips.services
27888 979 com.hualai
28043 2378 com.android.chrome:sandboxed_process0
31449 979 com.att.shm
31779 979 com.samsung.android.authfw
31846 979 com.samsung.android.server.iris
32014 979 com.samsung.android.MtpApplication
32045 979 com.samsung.InputEventApp
```
Reviewers: labath,xiaobai,aadsm,clayborg
Subscribers:
llvm-svn: 373931
Now that we do shell expansion on POSIX with the user's shel, this test
can potentially fail. This should ensure that we always use /bin/sh.
llvm-svn: 373804
I was writing an SB API client and it was crashing on:
bool DoExecute(SBDebugger dbg, char **command, SBCommandReturnObject &result) {
result = subcommand(dbg, "help");
That is because SBCommandReturnObject &result gets initialized inside LLDB by:
bool DoExecute(Args &command, CommandReturnObject &result) override {
// std::unique_ptr gets initialized here from `&result`!!!
SBCommandReturnObject sb_return(&result);
DoExecute(...);
sb_return.Release();
Differential revision: https://reviews.llvm.org/D67589
llvm-svn: 373775
Summary:
As we figured out in D67803, importing declarations from a temporary ASTContext that were originally from a persistent ASTContext
causes a bunch of duplicated declarations where we end up having declarations in the target AST that have no associated ASTImporter that
can complete them.
I haven't figured out how/if we can solve this in the current way we do things in LLDB, but in the modern-type-lookup this is solvable
as we have a saner architecture with the ExternalASTMerger. As we can (hopefully) make modern-type-lookup the default mode in the future,
I would say we try fixing this issue here. As we don't use the hack that was reinstated in D67803 during modern-type-lookup, the test case for this
is essentially just printing any kind of container in `std::` as we would otherwise run into the issue that required a hack like D67803.
What this patch is doing in essence is that instead of importing a declaration from a temporary ASTContext, we instead check if the
declaration originally came from a persistent ASTContext (e.g. the debug information) and we directly import from there. The ExternalASTMerger
is already connected with ASTImporters to these different sources, so this patch is essentially just two parts:
1. Mark our temporary ASTContext/ImporterSource as temporary when we import from the expression AST.
2. If the ExternalASTMerger sees we import from the expression AST, instead of trying to import these temporary declarations, check if we
can instead import from the persistent ASTContext that is already connected. This ensures that all records from the persistent source actually
come from the persistent source and are minimally imported in a way that allows them to be completed later on in the target AST.
The next step is to run the ASTImporter for these temporary expressions with the MinimalImport mode disabled, but that's a follow up patch.
This patch fixes most test failures with modern-type-lookup enabled by default (down to 73 failing tests, which includes the 22 import-std-module tests
which need special treatment).
Reviewers: shafik, martong
Reviewed By: martong
Subscribers: aprantl, rnkovacs, christof, abidh, JDevlieghere, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D68326
llvm-svn: 373711
This will allow us to write reusable scripted ThreadPlans, since
you can use key/value pairs with known keys in the plan to parametrize
its behavior.
Differential Revision: https://reviews.llvm.org/D68366
llvm-svn: 373675
Use this in the scripted breakpoint command. Added some tests for parsing
the key/value options. This uncovered a bug in handling parsing errors mid-line.
I also fixed that bug.
Differential Revision: https://reviews.llvm.org/D68363
llvm-svn: 373673
Summary:
Add new methods to SBDebugger to set IO files as SBFiles instead of
as FILE* streams.
In future commits, the FILE* methods will be deprecated and these
will become the primary way to set the debugger I/O streams.
Reviewers: JDevlieghere, jasonmolenda, labath
Reviewed By: labath
Subscribers: lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D68181
llvm-svn: 373563
Summary:
SBFile is a scripting API wrapper for lldb_private::File
This is the first step in a project to enable arbitrary python
io.IOBase file objects -- including those that override the read()
and write() methods -- to be used as the main debugger IOStreams.
Currently this is impossible because python file objects must first
be converted into FILE* streams by SWIG in order to be passed into
the debugger.
full prototype: https://github.com/smoofra/llvm-project/tree/files
Reviewers: JDevlieghere, jasonmolenda, zturner, jingham, labath
Reviewed By: labath
Subscribers: labath, mgorny, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D67793
llvm-svn: 373562
This makes sure that we associate DIEs that are imported from other CUs with the appropriate decl context.
Without this fix, nested classes can be dumped directly into their CU context if their parent was imported from another CU.
Reviewed By: teemperor, labath
Differential Revision: https://reviews.llvm.org/D68278
Patch by Jaroslav Sevcik!
llvm-svn: 373470
It is always doing work on behalf of another thread that presumably
has the mutex, so if it is calling SB API's it should have free access
to the mutex. This is the same decision as we made earlier with the
process RunLock.
Differential Revision: https://reviews.llvm.org/D68174
llvm-svn: 373280
Summary:
D67966 changes the output when dumping DWARF expressions and this updates basic_entry_values_x86_64 test to reflect this change.
llvm-svn: 373229
The problem with r370734 was that it removed the code for resetting the options in
OptionParsingStarting. This caused that once a 'frame select -r ...' command was executed,
we kept the relative index argument for all following 'frame select ...' invocations (even
the ones with an absolute index as they are the same command object). See rdar://55791276.
This relands the patch but keeps the code that resets the command options before execution.
llvm-svn: 373201
This somehow caused that 'frame select X' ends up being interpreted as 'frame select -r 1' when 'up' or 'down'
were run before 'frame select X'. See rdar://55791276.
Partly reverting to unbreak master. The changes that aren't reverted are the generic 'frame select -r' tests
that are obviously NFC and test existing behavior.
llvm-svn: 373194
Summary:
The ExternalASTMerger should use the ASTImporterSharedState. This allows it to
handle std::pair in LLDB (but the rest of libc++ is still work in progress).
Reviewers: martong, shafik, a.sidorin
Subscribers: rnkovacs, christof, JDevlieghere, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D68140
llvm-svn: 373193
A lot of commands are made up of CommandObjectMultiword with
subcommands. CommandObjectMultiword actually has some functionality
on its own that wasn't tested before.
llvm-svn: 373050
Summary: Usually, SIGINT and SIGSTOP don't imply a crash, e.g. SIGSTOP is sent on process launch and attach on some platforms.
Differential Revision: https://reviews.llvm.org/D67776
llvm-svn: 372961
The story so far: LLDB's modern type lookup mode has no (as in, 0%) test
coverage. It was supposed to be tested by hardcoding the default to 'true' and then running
the normal LLDB tests, but to my knowledge no one is doing that. As a around 130 tests
seem to fail with this mode enabled, we also can't just enable it globally for now.
As we touch the surrounding code all the time and also want to refactor parts of it, we
should be a bit more ambitious with our testing efforts.
So this patch adds two basic tests that enable this mode and do some
basic expression parsing which should hopefully be basic enough to not
break anywhere but still lets us know if this mode works at all (i.e. setting up the
ExternalASTMerger in LLDB, using its basic import functionality to move declarations
around and do some lookups).
llvm-svn: 372869
That flag was introduced in Clang 6.0, so this made the test fail
with Clang <= 5.0. As it only influences linking builtin libraries
like -m which aren't relevant for this test, we can drop this flag.
llvm-svn: 372827
This test streamlines our use of variables that are expected by
Makefile.rules throughout the test suite. Mostly it replaced
potentially dangerous overrides and updates of variables like CFLAGS
with safe assignments to variables reserved for this purpose like
CFLAGS_EXTRAS.
Differential Revision: https://reviews.llvm.org/D67984
llvm-svn: 372795
r366433 broke support for the system debugserver. Although the change
was well-intended, it (presumably) unintentionally removed the logic to
copy over the debugserver. As a result, even with
LLDB_USE_SYSTEM_DEBUGSERVER enabled, we ended up building, signing and
using the just-built debugserver.
This patch partially recovers the old behavior: when
LLDB_USE_SYSTEM_DEBUGSERVER is set we don't build debugserver and just
copy over the system one.
Differential revision: https://reviews.llvm.org/D67991
llvm-svn: 372786
Summary:
At the moment, when trying to import the `std` module in LLDB, we look at the imported modules used in the compiled program
and try to infer the Clang configuration we need from the DWARF module-import. That was the initial idea but turned out to
cause a few problems or inconveniences:
* It requires that users compile their programs with C++ modules. Given how experimental C++ modules are makes this feature inaccessible
for many users. Also it means that people can't just get the benefits of this feature for free when we activate it by default
(and we can't just close all the associated bug reports).
* Relying on DWARF's imported module tags (that are only emitted by default on macOS) means this can only be used when using DWARF (and with -glldb on Linux).
* We essentially hardcoded the C standard library paths on some platforms (Linux) or just couldn't support this feature on other platforms (macOS).
This patch drops the whole idea of looking at the imported module DWARF tags and instead just uses the support files of the compilation unit.
If we look at the support files and see file paths that indicate where the C standard library and libc++ are, we can just create the module
configuration this information. This fixes all the problems above which means we can enable all the tests now on Linux, macOS and with other debug information
than what we currently had. The only debug information specific code is now the iteration over external type module when -gmodules is used (as `std` and also the
`Darwin` module are their own external type module with their own files).
The meat of this patch is the CppModuleConfiguration which looks at the file paths from the compilation unit and then figures out the include paths
based on those paths. It's quite conservative in that it only enables modules if we find a single C library and single libc++ library. It's still missing some
test mode where we try to compile an expression before we actually activate the config for the user (which probably also needs some caching mechanism),
but for now it works and makes the feature usable.
Reviewers: aprantl, shafik, jdoerfert
Reviewed By: aprantl
Subscribers: mgorny, abidh, JDevlieghere, lldb-commits
Tags: #c_modules_in_lldb, #lldb
Differential Revision: https://reviews.llvm.org/D67760
llvm-svn: 372716
The log channels change depending on platform, so listing them breaks on
some platforms. Let's just check that the 'lldb' and 'dwarf' channels are
there which are independent of platform.
llvm-svn: 372701
This patch extends the Makefile.rules to build NeXT-style frameworks. It
also fixes a bug in the clean logic that would accidentally delete the
.mm source file instead of the .o object file.
Thanks a lot to Adrian who was instrumental is getting this to work!
llvm-svn: 372669
The test is now passing, so remove the expected failure. No other tests associated with the bug are passing, though, so only remove expected failure from this one test
llvm-svn: 372634
Summary:
In D61333 we dropped some code from ClangASTSource that checks if imported declarations
ended up in the right DeclContext. While this code wasn't tested by the test suite (or better, it was hit
by the test suite but we didn't have any checks that were affected) and the code seems pointless
(as usually Decls should end up in the right DeclContext), it actually broke the data formatters in LLDB
and causes a bunch of obscure bugs where structs suddenly miss all their members. The first report we got about
this was that printing a std::map doesn't work anymore when simply doing "expr m" (m is the std::map).
This patch reverts D61333 partly and reintroduces the check in a more stricter way (we actually check now that
we *move* the Decl and it is in a single DeclContext). This should fix all the problems we currently have until
we figure out how to properly fix the underlying issues. I changed the order of some std::map formatter tests
which is currently the most reliable way to test this problem (it's a tricky setup, see description below).
Fixes rdar://55502701 and rdar://55129537
--------------------------------------
Some more explanation what is actually going on and what is going wrong:
The situation we have is that if we have a `std::map m` and do a `expr m`, we end up seeing an empty map
(even if `m` has elements). The reason for this is that our data formatter sees that std::pair<int, int> has no
members. However, `frame var m` works just fine (and fixes all following `expr m` calls).
The reason for why `expr` breaks std::map is that we actually copy the std::map nodes in two steps in the
three ASTContexts that are involved: The debug information ASTContext (D-AST), the expression ASTContext
we created for the current expression (E-AST) and the persistent ASTContext we use for our $variables (P-AST).
When doing `expr m` we do a minimal import of `std::map` from D-AST to E-AST just do the type checking/codegen.
This copies std::map itself and does a minimal.import of `std::pair<int, int>` (that is, we don't actually import
the `first` and `second` members as we don't need them for anything). After the expression is done, we take
the expression result and copy it from E-AST to P-AST. This imports the E-AST's `std::pair` into P-AST which still
has no `first` and `second` as they are still undeserialized. Once we are in P-AST, the data formatter tries to
inspect `std::map` (and also `std::pair` as that's what the elements are) and it asks for the `std::pair` members.
We see that `std::pair` has undeserialized members and go to the ExternalASTSource to ask for them. However,
P-ASTs ExternalASTSource points to D-AST (and not E-AST, which `std::pair` came from). It can't point to E-AST
as that is only temporary and already gone (and also doesn't actually contain all decls we have in P-AST).
So we go to D-AST to get the `std::pair` members. The ASTImporter is asked to copy over `std::pair` members
and first checks if `std::pair` is already in P-AST. However, it only finds the std::pair we got from E-AST, so it
can't use it's map of already imported declarations and does a comparison between the `std::pair` decls we have
Because the ASTImporter thinks they are different declarations, it creates a second `std::pair` and fills in the
members `first` and `second` into the second `std::pair`. However, the data formatter is looking at the first
`std::pair` which still has no members as they are in the other decl. Now we pretend we have no declarations
and just print an empty map as a fallback.
The hack we had before fixed this issue by moving `first` and `second` to the first declaration which makes
the formatters happy as they can now see the members in the DeclContext they are querying.
Obviously this is a temporary patch until we get a real fix but I'm not sure what's the best way to fix this.
Implementing that the ClassTemplateSpecializationDecl actually understands that the two std::pair's are the same
decl fixes the issue, but this doesn't fix the bug for all declarations. My preferred solution would be to
complete all declarations in E-AST before they get moved to P-AST (as we anyway have to do this from what I can
tell), but that might have unintended side-effects and not sure what's the best way to implement this.
Reviewers: friss, martong
Reviewed By: martong
Subscribers: aprantl, rnkovacs, christof, abidh, JDevlieghere, lldb-commits, shafik
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D67803
llvm-svn: 372549
If one reverts D66398 then the TestDataFormatterStdList does fail - as the C++
formatters are initialized in the opposite order. But the current state of
trunk does not mind the order for C++ formatters.
It is using now a single std::vector as suggested by Pavel Labath.
Differential Revision: https://reviews.llvm.org/D66654
llvm-svn: 372424
different compilers will put different things into __PRETTY_FUNCTION__.
For instance gcc will not put a " " in the "const char *" argument,
causing our regex matching to fail.
This patch relaxes the regexes in this test to account for this
difference.
llvm-svn: 372224
Summary:
Currently our expression evaluators only prints very basic errors that are not very useful when writing complex expressions.
For example, in the expression below the user made a type error, but it's not clear from the diagnostic what went wrong:
```
(lldb) expr printf("Modulos are:", foobar%mo1, foobar%mo2, foobar%mo3)
error: invalid operands to binary expression ('int' and 'double')
```
This patch enables full Clang diagnostics in our expression evaluator. After this patch the diagnostics for the expression look like this:
```
(lldb) expr printf("Modulos are:", foobar%mo1, foobar%mo2, foobar%mo3)
error: <user expression 1>:1:54: invalid operands to binary expression ('int' and 'float')
printf("Modulos are:", foobar%mo1, foobar%mo2, foobar%mo3)
~~~~~~^~~~
```
To make this possible, we now emulate a user expression file within our diagnostics. This prevents that the user is exposed to
our internal wrapper code we inject.
Note that the diagnostics that refer to declarations from the debug information (e.g. 'note' diagnostics pointing to a called function)
will not be improved by this as they don't have any source locations associated with them, so caret or line printing isn't possible.
We instead just suppress these diagnostics as we already do with warnings as they would otherwise just be a context message
without any context (and the original diagnostic in the user expression should be enough to explain the issue).
Fixes rdar://24306342
Reviewers: JDevlieghere, aprantl, shafik, #lldb
Reviewed By: JDevlieghere, #lldb
Subscribers: usaxena95, davide, jingham, aprantl, arphaman, kadircet, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D65646
llvm-svn: 372203
I don't know what the intent of parts of this test were. We set a
bunch of breakpoints and ran from one to the other, doing "self.runCmd("thread backtrace")"
then continuing to the next one. We didn't actually verify the contents of the backtrace,
nor that we hit the breakpoints we set in any particular order. The only actual test was
to run sel_getName at two of these stops.
So I reduced the test to just stopping at the places where we were actually going to run
an expression, and tested the expression.
llvm-svn: 372196
This test is about disassembling symbols in a framework without debug information.
So we don't need to run it once per debug info flavor.
llvm-svn: 372193
Jim pointed out that the LLDB global variables should only be available
in interactive mode. When used from a command for example, their values
might be stale or not at all what the user expects. Therefore we want to
explicitly make these variables unavailable.
Differential revision: https://reviews.llvm.org/D67685
llvm-svn: 372192
This test is failing on the Fedora bot (staging). Rather than failing
with an IndexError, we should trigger an assert and dump the log when
the regex doesn't match.
llvm-svn: 372052
This ensures that if the assertion fails we dump the log content. This
should help me investigate what the output looks like on Windows, where
the test is failing.
llvm-svn: 371899
The new centralized way of doing API logging through the reproducer
macros is lacking a way to easily correlate instances of API objects.
Logging the this pointer makes that significantly easier. For methods
this is now always passed as the first argument, similar to the self
argument in Python.
This patch also adds a test case for API logging, which uncovered that
we were not quoting strings.
Differential revision: https://reviews.llvm.org/D67538
llvm-svn: 371885
These tests were temporarily missing when the big Makefile
simplification patch landed, so this just applies the same change
to these tests.
llvm-svn: 371738
After reverting the deletion of the functionalities/breakpoint tests,
we now have some tests twice in the test/ folder which breaks dotest:
* commands/breakpoint/basic
* functionalities/breakpoint/breakpoint_command
After looking over these tests, I think it makes sense to only
keep the original functionalities/ folder. The commands/breakpoint/basic
test are not exclusively testing the breakpoint command itself, so
they shouldn't be in commands/ in the first place. Note that these
folders have identical contents (beside small adjustments regarding
the Makefile which landed after the restructuring).
llvm-svn: 371734
Add support for evaluating DW_OP_entry_value. This involves parsing
DW_TAG_call_site_parameter and wiring the information through to the expression
evaluator.
rdar://54496008
Differential Revision: https://reviews.llvm.org/D67376
llvm-svn: 371668
It seems when I restructured the test folders the functionalities/breakpoint
was deleted. This just reverts this change and re-adds the tests.
llvm-svn: 371512
Summary:
This patch adds support of watchpoints to the old `ProcessWindows` plugin.
The `ProcessWindows` plugin uses the `RegisterContext` to set and reset
watchpoints. The `RegisterContext` has some interface to access watchpoints,
but it is very limited (e.g. it is impossible to retrieve the last triggered
watchpoint with it), that's why I have implemented a slightly different
interface in the `RegisterContextWindows`. Moreover, I have made the
`ProcessWindows` plugin responsible for search of a vacant watchpoint slot,
because watchpoints exist per-process (not per-thread), then we can place
the same watchpoint in the same slot in different threads. With this scheme
threads don't need to have their own watchpoint lists, and it simplifies
identifying of the last triggered watchpoint.
Reviewers: asmith, stella.stamenova, amccarth
Reviewed By: amccarth
Subscribers: labath, zturner, leonid.mashinskiy, abidh, JDevlieghere, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D67168
llvm-svn: 371166
The bugreport command exists to create domain-specific bug reports.
Currently it has one implementation for filing bugs on the unwinder. As
far as we can tell, it has never been of use. Although not exactly the
same as the reproducers, it's a bit confusing to have two parallel
command trees for (kind of) the same thing.
Differential revision: https://reviews.llvm.org/D65469
llvm-svn: 371132
I'm still unable to reproduce this locally, so let's see if this
is enough to make the bots happy. The missing dimension parameter
seems to be the biggest difference between these tests and
TestIOHandlerCompletion.py which runs just fine on the same bot,
so that's the motivation for trying this out.
llvm-svn: 371077
This appears to be a really ancient way of running the test suite. It
is also completely disfunctional now, and probably has been for a long
time.
llvm-svn: 371020
Summary:
In r367234 we introduced a central place to hold the set up commands for
the various ways we have of launching lldb. However, a number of
commands still remained outside of that.
This patch moves the remaining set up commands into this function, which
allows us to remove manual clang module path setting code in
TestBatchMode.
One unfortunate victim of this approach is TestSTTYBeforeAndAfter which,
due to how it launches lldb (pexpect->expect->lldb), fails get the
quoting right. It would be possible to fix the quoting there, it would be a bit
icky, and none of the commands in this list are really relevant for what this
test is doing, so I just remove the commands outright.
Reviewers: JDevlieghere, jankratochvil
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D67173
llvm-svn: 371019
This reverts my change to pseudo_barrier.h which isn't necessary anymore
after Fred's fix to debugserver and caused TestThreadStepOut to fail.
llvm-svn: 370963
Python 3 iteration calls the next() method instead of next() and
value_iter only implemented the Python 2 version.
Differential revision: https://reviews.llvm.org/D67184
llvm-svn: 370954
Python 3 calls __bool__() instead of __len__() and lldb.value only
implemented the __len__ method. This adds the __bool__() implementation.
Differential revision: https://reviews.llvm.org/D67183
llvm-svn: 370953
plugin.
Unfortunately the test is currently XFAILed because of missing changes
to the clang driver.
Differential Revision: https://reviews.llvm.org/D67124
llvm-svn: 370931
The flakiness on our local machines seems to come for a race in the kernel
between task_suspend and the creation of the Mach exceptions for the threads
that hit breakpoints. The debugserver code is written with the assumption
that the kernel will be able to provide us with all the exceptions for a
given task once task_suspend returns. On machines with higher core counts,
this seems not to be the case. The first batch of exceptions we get after
task_suspend does not contain exceptions for all the threads that have hit
a breakpoint, thus they get misreprorted in the first stop packet.
Adding a 1ms timeout to the call that retrieves the batch of exceptions
seems to workaround the issue reliably on our machines, and it shoulnd't
impact standard debugging scenarios too much (a stop will incur an additional
1ms delay). We'll be talking to the kernel team to figure out the right
contract for those APIs.
This patch also reverts part of Jonas' previous workaround for the
issue (r370785).
llvm-svn: 370916
Summary:
We got a radar that printing small floats is not very user-friendly in LLDB as we print them with up to
100 leading zeroes before starting to use scientific notation. This patch changes this by already using
scientific notation when we hit 6 padding zeroes by default and moves this value into a target setting
so that users can just set this number back to 100 if they for some reason preferred the old behaviour.
This new setting is influencing how we format data, so that's why we have to reset the data visualisation
cache when it is changed.
Note that we have always been using scientific notation for large numbers because it seems that
the LLVM implementation doesn't support printing out the padding zeroes for them. I would have fixed
that if it was trivial, but looking at the LLVM implementation for this it seems that this is not as trivial
as it sounds. I would say we look into this if we ever get a bug report about someone wanting to have
a large amount of trailing zeroes in their numbers instead of using scientific notation.
Fixes rdar://39744137
Reviewers: #lldb, clayborg
Reviewed By: clayborg
Subscribers: JDevlieghere, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D67001
llvm-svn: 370880
Summary:
I'm doing this mainly for consistency, but there are also other cleanups
that will be enabled by this (e.g., the automatic setting of
clang-modules-cache-path setting).
Reviewers: teemperor, JDevlieghere
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D67082
llvm-svn: 370858
Summary:
Instead of each test case knowing its depth relative to the test root,
we can just have dotest add the folder containing Makefile.rules to the
include path.
This was motivated by r370616, though I have been wanting to do this
ever since we moved to building tests out-of-tree.
The only manually modified files in this patch are lldbinline.py and
plugins/builder_base.py. The rest of the patch has been produced by this
shell command:
find . \( -name Makefile -o -name '*.mk' \) -exec sed --in-place -e '/LEVEL *:\?=/d' -e '1,2{/^$/d}' -e 's,\$(LEVEL)/,,' {} +
Reviewers: teemperor, aprantl, espindola, jfb
Subscribers: emaste, javed.absar, arichardson, christof, arphaman, lldb-commits
Differential Revision: https://reviews.llvm.org/D67083
llvm-svn: 370845
Summary: This doesn't seem to be used anymore (at least I can't find any reference to this in the LLDB repo and it doesn't seem to be a standalone script). Git says this was once some new curses mode for viewing test results.
Reviewers: clayborg, JDevlieghere
Reviewed By: JDevlieghere
Subscribers: JDevlieghere, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D67064
llvm-svn: 370804
On "fast" macOS machines, the TestConcurrentMany*.py tests would fail
randomly with different numbers of breakpoints, watchpoints, etc. This
seems to be avoidable by giving the threads a little time to breath
after the passing the synchronization barrier. This is far from a
structural fix but it reduces the flakiness.
llvm-svn: 370785
Summary:
The gui command requires curses support, which can be disabled at
compile time. This patch adds the ability to detect this situation in
the test suite and skip the test accordingly.
Reviewers: teemperor, jankratochvil
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D67073
llvm-svn: 370658
Summary:
Right now our argument completions are rather cryptic for command options as they only list the letters:
```
(lldb) breakpoint set -
Available completions:
-G
-C
-c
-d
-i
-o
-q
-t
-x
[...]
```
With the new completion API we can easily extend this with the flag description so that it looks like this now:
```
(lldb) breakpoint set -
Available completions:
-G -- The breakpoint will auto-continue after running its commands.
-C -- A command to run when the breakpoint is hit, can be provided more than once, the commands will get run in order left to right.
-c -- The breakpoint stops only if this condition expression evaluates to true.
-d -- Disable the breakpoint.
-i -- Set the number of times this breakpoint is skipped before stopping.
-o -- The breakpoint is deleted the first time it stop causes a stop.
-q -- The breakpoint stops only for threads in the queue whose name is given by this argument.
-t -- The breakpoint stops only for the thread whose TID matches this argument.
-x -- The breakpoint stops only for the thread whose index matches this argument.
```
The same happens with --long-options now.
Reviewers: #lldb, labath
Reviewed By: labath
Subscribers: labath, JDevlieghere, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D67063
llvm-svn: 370628
Summary:
This adds a basic test for the GUI command. Just tests that it starts up, that we can quit the gui
and help window, and that the basic UI elements are rendered. Mostly testing the waters how
testing this command will do on the bots or if that will cause some serious issues when we do
fancy ncurses stuff.
Reviewers: labath, clayborg
Reviewed By: labath
Subscribers: JDevlieghere, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D67018
llvm-svn: 370625
Summary:
As discussed on lldb-dev, this patch moves some LLDB tests into a hierarchy that more closely
resembles the commands we use in the LLDB interpreter. This patch should only move tests
that use the command interpreter and shouldn't touch any tests that primarily test the SB API.
Reviewers: #lldb, jfb, JDevlieghere
Reviewed By: #lldb, JDevlieghere
Subscribers: dexonsmith, arphaman, JDevlieghere, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D67033
llvm-svn: 370605
Currently tests using expect_prompt are failing on the Python 3 bot with
an error saying "argument must be str, not bytes". I don't have a Python
3 build handy, but I suspect this might fix that.
llvm-svn: 370526
Summary:
While working on r370054, i've found it frustrating that the test output
was compeletely unhelpful in case of failures. Therefore I've decided to
improve that. In this I reuse the PExpectTest class, which was one of
our mechanisms for running pexpect tests, but which has gotten orhpaned
in the mean time.
I've replaced the existing send methods with a "expect" method, which
I've tried to design so that it has a similar interface to the expect
method in regular non-pexpect dotest tests (as it essentially does
something very similar). I've kept the ability to dump the transcript of
the pexpect communication to stdout in the "trace" mode, as that is a
very handy way to figure out what the test is doing. I've also removed
the "expect_string" method used in the existing tests -- I've found this
to be unhelpful because it hides the message that would be normally
displayed by the EOF exception. Although vebose, this message includes
some important information, like what strings we were searching for,
what were the last bits of lldb output, etc. I've also beefed up the
class to automatically disable the debug info test duplication, and
auto-skip tests when the host platform does not support pexpect.
This patch ports TestMultilineCompletion and TestIOHandlerCompletion to
the new class. It also deletes TestFormats as it is not testing anything
(definitely not formats) -- it was committed with the test code
commented out (r228207), and then the testing code was deleted in
r356000.
Reviewers: teemperor, JDevlieghere, davide
Subscribers: aprantl, lldb-commits
Differential Revision: https://reviews.llvm.org/D66954
llvm-svn: 370449
Currently, lit tests don't set neither the module cache for building
inferiors nor the module cache used by lldb when running tests.
Furthermore, we have several places where we rely on the path to the
module cache being always the same, rather than passing the correct
value around. This makes it hard to specify a different module cache
path when debugging a a test.
This patch reworks how we determine and pass around the module cache
paths and fixes the omission on the lit side. It also adds a sanity
check to the lit and dotest suites.
Differential revision: https://reviews.llvm.org/D66966
llvm-svn: 370394
It used to be possible to enable logging through environment variables
read by dotest. This approach is deprecated, as stated in the dotest
help output. Instead --channel should be used.
Differential revision: https://reviews.llvm.org/D66920
llvm-svn: 370387
This removes the curses result formatter which appears to be broken.
Passing --curses to dotest.py screws up my terminal and doesn't run any
tests. It even crashes Python on occasion.
Differential revision: https://reviews.llvm.org/D66917
llvm-svn: 370386
This removes support for reading the LLDB_TEST_ARGUMENTS environment
variable and instead requires all arguments to be specified as part of
the invocation. This ensures that dotest.py invocations are easily
repeatable.
Differential revision: https://reviews.llvm.org/D66912
llvm-svn: 370278
This argument was used by dosep.py to pass information around from the
workers. With dosep.py gone, I'm fairly sure we don't need this any
longer.
llvm-svn: 370266
I was looking at the session directory logic for unrelated reasons and
noticed that the logic spread out across dotest. This simplifies things
a bit by moving the logic together.
llvm-svn: 370259
Disable the two failing tests until Raphael has a chance to investigate:
Failing Tests (2):
lldb-Suite :: functionalities/completion/TestCompletion.py
lldb-Suite :: functionalities/target_command/TestTargetCommand.py
llvm-svn: 370237
Now that all supported build systems create a valid dotest.py
invocation, we no longer need to guess the location of the lldb binary
and Python directory.
Differential revision: https://reviews.llvm.org/D66896
llvm-svn: 370234
Now that all supported build systems create a valid dotest.py
invocation, we no longer need to guess the directory where any of the
llvm tools live. Additionally, the current logic is incomplete: it
doesn't try to find any other tools than FileCheck, such as dsymutil for
example.
If no FileCheck is provided, we should print a warning and skip the
tests that need it, but that's not part of this patch.
Differential revision: https://reviews.llvm.org/D66893
llvm-svn: 370232
This patch removes the -q (quiet) flag and changing the default
behavior. Currently the flag serves two purposes that are somewhat
contradictory, as illustrated by the difference between the argument
name (quiet) and the configuration flag (parsable). On the one hand it
reduces output, but on the other hand it prints more output, like the
result of individual tests. My proposal is to guard the extra output
behind the verbose flag and always print the individual test results.
Differential revision: https://reviews.llvm.org/D66837
llvm-svn: 370226
Apparently inline tests stop running anything after an empty line
behind an self.expect, which is a very good approach that could
never cause people to write tests that never run.
This patch removes all the empty lines so that all this test
is actually run. Also fixes the broken expects that only passed
because they weren't run before.
llvm-svn: 370195
The refactoring patch for the option completion broke the completion
for ambiguous long options. As this feature was also untested (as
testing ambiguous options with the current test methods is impossible),
I just noticed now. This patch restores the old behavior and adds a
test for this feature.
llvm-svn: 370185
The results port was used by dosep.py to deal with test results coming
form different processes. With dosep.py gone, I don't think we need this
any longer.
Differential revision: https://reviews.llvm.org/D66811
llvm-svn: 370090
pexpect gives as raw data going to a terminal. This means that if the
completed line does not fit the emulated line, the returned data will
contain line breaks. On my machine these line breaks happened to be
inside the "iohandler/completion" string that the test was searching
for.
Work around this by telling pexpect to emulate a very wide terminal.
llvm-svn: 370054
Otherwise dotest doesn't run the test and just lets it always pass.
Also update the comment to explain that we do directory and not
file completion.
llvm-svn: 370047
On the command line we usually insert a space after a completion to indicate that
the completion was successful. After the completion API refactoring, this also
happens with directories which essentially breaks file path completion (as
adding a space terminates the path and starts a new arg). This patch restores the old
behavior by again allowing partial completions. Also extends the iohandler
and SB API tests as the implementation for this is different in Editline
and SB API.
llvm-svn: 370043
Today I discovered the skipLongRunningTest decorator and to my surprise
all the tests were passing without the decorator. They don't seem to be
that expensive either, they take a few seconds but we have tests that
take much longer than that. As such I propose to remove the decorator
and enable them by default.
Differential revision: https://reviews.llvm.org/D66774
llvm-svn: 369995
We have started to see the no_binary version of this test
fail. The reason is that the binary was being removed
before the spawn actually launched the inferior. Add a
simple filesystem based synchronization to avoid this race.
llvm-svn: 369930
With this patch dotest.py will print the full invocation whenever it
fails to parse its arguments. The dotest invocation is usually build up
with different inputs, potentially coming from CMake, lldb-dotest, lit
or passed directly. This can make debugging hard, especially on CI,
where there might be another layer of indirection. This aims to make
that a bit easier.
llvm-svn: 369922
It looks like running without this argument was supported
for legacy reasons, but a Xcode 11 beta made the argument
mandatory for our usecase.
llvm-svn: 369709
the platform in the setUp/tearDown methods. I want to migrate the
re-instatement of the correct plaform to the setUp base method but
haven't had time to look at that yet, so I want to land this handful
of fixes until I get to it.
Differential revision: https://reviews.llvm.org/D66331
llvm-svn: 369484
We cannot override the DWARF version in the CFLAGS_EXTRA because they
are used by tests that explicitly build without debug info. Instead, we
pass them through the regular CFLAGS.
llvm-svn: 369477
Summary:
The test for conditional breakpoints on Windows was skipped because
there was no expression evaluation support at the time it was written.
After removing the annotation and testing it again, the test is passing.
http://lists.llvm.org/pipermail/lldb-dev/2019-August/015405.html
Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
Reviewers: stella.stamenova, jingham
Subscribers: lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D66499
llvm-svn: 369453
Summary:
This commit fixes some typo I found while exploring LLDB's codebase.
Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
Subscribers: lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D66452
llvm-svn: 369313
Summary:
This can help `lldb-vscode` handle launch commands associate with remote platform
attach request have field `attachCommands` to handle attach specific commands
add a corresponding one for launch request
if no launch command is provided, create a new target and launch; otherwise, execute the launch command
Differential Revision: https://reviews.llvm.org/D65363
Patch by Wanyi Ye <kusmour@gmail.com>
llvm-svn: 369296
Instead of relying that three tabs show all completions, we should
show all remaining completions which will always stop the mode
where we show completions. Should fix this test on systems that
somehow have more completions that our normal LLDB (as they
would end up being stuck in the mode where we show completions).
llvm-svn: 369293
On the matrix bot on GreenDragon [1] we want to run the test suite
against different DWARF versions. The idea here is not to replace
targeted tests for certain DWARF features, but rather to provide an easy
way to support this configuration.
[1] http://green.lab.llvm.org/green/view/LLDB/job/lldb-cmake-matrix/
Differential revision: https://reviews.llvm.org/D66370
llvm-svn: 369272
These tests are mostly trying to reach the different completion functions
in CommandCompletions.cpp (::ArchitectureNames, ::DiskFiles, ::Modules).
llvm-svn: 369249
There was a little bit of logic in the StopInfoBreakpoint::PerformAction
that would null out the StopInfo once we had a completed plan so that the
next call to GetStopInfo would replace it with the StopInfoThreadPlan.
But the stop-hooks check for whether a thread stopped for a reason didn't
trigger this conversion. So I added an API to do that directly, and then
called it where before we just reset the StopInfo.
<rdar://problem/54270767>
Differential Revision: https://reviews.llvm.org/D66241
llvm-svn: 369052
Summary:
Currently the heuristic used in ClangASTContext::CreateRecordType to identify an anonymous class is that there is that name is a nullptr or simply a null terminator. This heuristic is not accurate since it will also sweep up unnamed classes and lambdas. The improved heuristic relies on the requirement that an anonymous class must be contained within a class.
Differential Revision: https://reviews.llvm.org/D66175
llvm-svn: 368937
Summary:
It seems this was an unintended side-effect of D26698. AFAICT, these
functions did return an empty string before that patch, and the patch
contained code which attempted to ensure that, but those efforts were
negated by ConstString::AsCString, which by default returns a nullptr
even for empty strings.
This patch:
- fixes the GetOutput/Error methods to really return empty strings
- adds and explicit test for that
- removes a workaround in lldbtest.py, which was masking this problem
from our other tests
Reviewers: jingham, clayborg
Subscribers: zturner, lldb-commits
Differential Revision: https://reviews.llvm.org/D65739
llvm-svn: 368806
Summary: Thanks to Hui Huang and reviewers for all the help with this patch!
Reviewers: labath, jfb, clayborg
Reviewed By: labath
Subscribers: Hui, clayborg, dexonsmith, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D61687
llvm-svn: 368776
Summary: Thanks to Hui Huang and the reviewers for all the help with this patch.
Reviewers: labath, Hui, jfb, clayborg, amccarth
Reviewed By: labath
Subscribers: amccarth, compnerd, dexonsmith, mgorny, jfb, teemperor, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D63165
llvm-svn: 368759
We have no test coverage for the IOHandler code that is doing the
completion in the command line. This is adding a pexpect-based test
as a preparation for the switch to using CompletionRequest in the
whole completion machinery.
llvm-svn: 368679
Summary:
Our IR rewriting infrastructure currently fails when it encounters a variable which has no metadata associated.
This causes dynamic_cast to fail as in this case IRForTarget considers the type info pointers ('@_ZTI...') to be
variables without associated metadata. As there are no variables for these internal variables, this is actually
not an error and dynamic_cast would work fine if we didn't throw this error.
This patch fixes this by removing this diagnostics code. In case we would actually hit a variable that has no
metadata (but is supposed to have), we still have the error in the expression log so this shouldn't make it
harder to diagnose any missing metadata errors.
This patch should fix dynamic_cast and also adds a bunch of test coverage to that language feature.
Fixes rdar://10813639
Reviewers: davide, labath
Reviewed By: labath
Subscribers: friss, labath, abidh, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D65932
llvm-svn: 368511
If a bitfield doesn't fit into the child_byte_size'd window at
child_byte_offset, move the window forward until it fits. The problem
here is that Value has no notion of bitfields and thus the Value's
DataExtractor is sized like the bitfields CompilerType; a sequence of
bitfields, however, can be larger than their underlying type.
This was not in the big-endian-derived DWARF 2 bitfield attributes
because their offsets were counted from the end of the window, so they
always fit.
rdar://problem/53132189
Differential Revision: https://reviews.llvm.org/D65492
llvm-svn: 368226
Summary:
The change https://reviews.llvm.org/D55575 modified ClangASTContext::CreateParameterDeclaration to call decl_ctx->addDecl(decl); this caused a regression since the existing code in DWARFASTParserClang::ParseChildParameters is called with the containing DeclContext. So when end up with cases where we are parsing a parameter for a member function and the parameter is added to the CXXRecordDecl as opposed to the CXXMethodDecl. This example is given in the regression test TestBreakpointInMemberFuncWNonPrimitiveParams.py which without this fix in a modules build leads to assert on setting a breakpoint in a member function with non primitive parameters. This scenario would be common when debugging LLDB or clang.
Differential Revision: https://reviews.llvm.org/D65414
llvm-svn: 367726
Summary: We have been seeing increased reports of performance issue around large project and formatting std::function variables especially in functions signatures in back traces. There are some possible fixes but exploring those fixes may take time and it is better to temporarily disable the formatter due to its impact and re-enable it once we have a fix.
Differential Revision: https://reviews.llvm.org/D65666
llvm-svn: 367701
For security reasons, DYLD_INSERT_LIBRARIES is not propagated to a child
process. This breaks the skipIfSanitized decorator, which checks for the
environment variable being set. Instead, always set the ASAN_OPTIONS and
make the decorator check for that.
Differential revision: https://reviews.llvm.org/D65594
llvm-svn: 367595
This test was frequently hanging on Windows, causing a timeout after
10 minutes. The short delay (100 microsecond) in the sample program
could cause a deadlock in the Windows thread pool, as I've explained
in the test program's comments.
Now that it doesn't hang, it passes reliably, so I've removed the
Windows-specific XFAIL.
I've tried to clarify the comments in TestThreadSpecificGBreakpoint.py
by eliminating some redundancy and typos, and I simplified away a
couple unnecessary assignments.
Differential Revision: https://reviews.llvm.org/D65546
llvm-svn: 367573
I was going through some of the old bugs and came across PR21069 which I
was able to reproduce. The issue is that we match the regex `^foo`
against the `DW_AT_name` in the DWARF, which for our anonymous function
is indeed `foo`. However, when we get the function name from the symbol
context, the result is `(anonymous namespace)::foo()`. This throws off
completions, which assumes that it's appending to whatever is already
present on the input, resulting in a bogus
`b fooonymous\ namespace)::foo()`.
Bug report: https://llvm.org/PR21069
Differential revision: https://reviews.llvm.org/D65498
llvm-svn: 367455
Now that the Xcode project is removed, I want to focus on dotest as a
test framework, and remove its driver capabilities for which we already
rely on llvm's lit. Removing multiprocessing is the first step in that
direction.
Differential revision: https://reviews.llvm.org/D65311
llvm-svn: 367331
Summary:
Tab completing inside the multiline expression command can cause LLDB to crash. The easiest way
to do this is to go inside a frame with at least one local variable and then try to complete:
(lldb) expr
1. a[tab]
Reason for this was some mixup when we calculate the cursor position. Obviously we should calculate
the offset inside the string by doing 'end - start', but we are doing 'start - end' (which causes the offset to
become -1 which will lead to some out-of-bounds reading).
Fixes rdar://51754005
I don't see any way to test this as the *multiline* expression completion is completely untested at the moment
and I don't think we have any existing code for testing infrastructure for it.
Reviewers: shafik, davide, labath
Reviewed By: labath
Subscribers: abidh, lldb-commits, davide, clayborg, labath
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D64995
llvm-svn: 367308
Compare the directory paths returned by lldb-vscode against realpaths
rather than apparent paths. This matches lldb-vscode behavior
and therefore fixes test failures when one of the parent directories
of the source tree is a symlink.
Differential Revision: https://reviews.llvm.org/D65432
llvm-svn: 367291
The test was not previously run due to decorator bug (fixed in r366903).
It is not a regression and is probably related to the other failing
test, so just disable it.
llvm-svn: 367285
Summary:
This doubles the 3 tests running right now on linux by also executing each test with libraries-svr4 enabled.
Not sure if there's a better way to do this as I had to copy/paste all the decorators as well...
Reviewers: labath, clayborg, xiaobai
Reviewed By: labath
Subscribers: srhines, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D65129
llvm-svn: 367247
rL357954 did increase `packet-timeout` 1sec -> 5secs. Which is IMO about the
maximum timeout reasonable for regular use. But for testsuite I think the
timeout should be higher as the testsuite runs in parallel and it can be run
even on slow hosts and with other load (moreover if it runs on some slow arch).
I have chosen 60 secs, that should be enough hopefully. Larger value could
make debugging with hanging `lldb-server` annoying.
This patch was based on this testsuite timeout:
http://lab.llvm.org:8014/builders/lldb-x86_64-fedora/builds/546/steps/test/logs/stdio
FAIL: test_connect (TestGDBRemoteClient.TestGDBRemoteClient)
Test connecting to a remote gdb server
----------------------------------------------------------------------
Traceback (most recent call last):
File "/home/jkratoch/slave-lldb-x86_64-fedora/lldb-x86_64-fedora/llvm/tools/lldb/packages/Python/lldbsuite/test/functionalities/gdb_remote_client/TestGDBRemoteClient.py", line 13, in test_connect
process = self.connect(target)
File "/home/jkratoch/slave-lldb-x86_64-fedora/lldb-x86_64-fedora/llvm/tools/lldb/packages/Python/lldbsuite/test/functionalities/gdb_remote_client/gdbclientutils.py", line 480, in connect
self.assertTrue(error.Success(), error.description)
AssertionError: False is not True : failed to get reply to handshake packet
Differential Revision: https://reviews.llvm.org/D65271
llvm-svn: 367234
We noticed that TestInferiorCrashing.py and TestRecursiveInferior.py are
the second and third slowest tests in the test suite. Splitting them up
allows lit to schedule them more effectively.
llvm-svn: 367077
Dotest contains code to clear DYLD_LIBRARY_PATH for the inferior to not
propagate sanitized builds. However, it's possible that we want to
inject a different library path with `--inferior-env`. To make that work
correctly, we need to do that *after* clearing DYLD_LIBRARY_PATH.
llvm-svn: 367054
Mark the process as stopped when SIGSTOP arrives. This is necessary
for lldb-server to generate correct response to 'process interrupt',
and therefore to prevent the whole stack crashing when process
is stopped.
Thanks to Pavel Labath for the tip.
Differential Revision: https://reviews.llvm.org/D65289
llvm-svn: 367047
Summary:
Due to a logic error, lldb-server ended up asserting/crashing every time
the debugged process attempted an execve(). This fixes the error, and
extends TestExec to work on other platforms too. The "extension"
consists of avoiding non-standard posix_spawn extensions and using the
classic execve() call, which should be available on any platform that
actually supports re-execing. I change the test decorator from
@skipUnlessDarwin to @skipIfWindows.
Reviewers: clayborg, jasonmolenda
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D65207
llvm-svn: 366985
Summary: update some test decorates that can actually pass on andriod aarch64
Patch by Wanyi Ye <kusmour@gmail.com>
Differential Revision: https://reviews.llvm.org/D64767
llvm-svn: 366858
On slower machines the vscode testcases were sometimes hanging:
1910 ? Sl 0:00 | \_ /usr/bin/python .../llvm/tools/lldb/test/dotest.py ... -p TestVSCode_setBreakpoints.py
2649 ? Sl 0:00 | \_ .../build/bin/lldb-vscode
2690 ? S 0:00 | \_ .../build/bin/lldb-server gdbserver --fd=9 --native-regs --setsid
2708 ? t 0:00 | \_ .../build/lldb-test-build.noindex/tools/lldb-vscode/breakpoint/TestVSCode_setBreakpoints.test_functionality/a.out
A reproducer of the racy bug for send_recv():
# self.send_packet(command)
#+ import time
#+ time.sleep(1)
# done = False
I guess `request_continue` was probably originally intended to be synchronous
but then it isn't and this code has been leftover there.
Differential revision: https://reviews.llvm.org/D65163
llvm-svn: 366850
Summary:
Delete the duplicate func `skipIfTargetAndroid`
Fix the old one. It didn't work for missing an argument `bugnumber`, this somehow made the decorator failed
Differential Revision: https://reviews.llvm.org/D64583
Patch by Wanyi Ye <kusmour@gmail.com>
llvm-svn: 366771
Summary:
We assume in LLDB that every type comes from an ASTContext with an associated ClangASTContext.
However the types inside the ClangModuleDeclVendor don't have a ClangASTContext so we end up
crashing whenever we create a CompilerType for one of these types.
Simplest way to trigger this bug is to just look up NSObject from a module:
(lldb) expr @import Foundation
(lldb) type lookup NSObject
Assertion failed: (m_type_system != nullptr), function CompilerType, file /Users/teemperor/llvm1/llvm-project/lldb/source/Symbol/CompilerType.cpp, line 39.
This patch just creates a ClangASTContext for the ASTContext used by ClangModuleDeclVendor.
Reviewers: davide, shafik
Reviewed By: davide
Subscribers: lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D64989
llvm-svn: 366653
Summary: lldb-mi has been removed, but there are still a bunch of references in the code base. This patch removes all of them.
Reviewers: JDevlieghere, jfb
Reviewed By: JDevlieghere
Subscribers: dexonsmith, ki.stfu, mgorny, abidh, jfb, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D64992
llvm-svn: 366590
Summary:
Add __kernel_rt_sigreturn to the list of trap handlers for Linux (it's
used as such on aarch64 at least), and __restore_rt as well (used on
x86_64).
Skip decrement-and-recompute for trap handlers in
InitializeNonZerothFrame, as signal dispatch may point the child frame's
return address to the start of the return trampoline.
Parse the 'S' flag for signal handlers from eh_frame augmentation, and
propagate it to the unwind plan.
Reviewers: labath, jankratochvil, compnerd, jfb, jasonmolenda
Reviewed By: jasonmolenda
Subscribers: clayborg, MaskRay, wuzish, nemanjai, kbarton, jrtc27, atanasyan, jsji, javed.absar, kristof.beyls, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D63667
llvm-svn: 366580
When two .c files define a type of the same name, lldb
just picks one and uses it regardless of context. That is
not correct. When stopped in a frame in one of the .c files
that define this type, it should use that local definition.
This commit just adds a test that checks for the correct
behavior. It is currently xfailed.
llvm-svn: 366507
Summary:
We currently don't support offsetof in the expression evaluator as it is implemented as a macro
(which then calls __builtin_offsetof) in stddef.h. The best solution would be to include that
header (or even better, import Clang's builtin module), but header-parsing and
(cross-platform) importing modules is not ready yet.
Until we get this working with modules I would say we add the macro to our existing macro list
as we already do with other macros from stddef.h/stdint.h. We should be able to drop all of them
once we can import the relevant modules by default.
rdar://26040641
Reviewers: shafik, davide
Reviewed By: davide
Subscribers: clayborg, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D64917
llvm-svn: 366476
If a core file has an EFI version string which includes a UUID
(similar to what it returns for the kdp KDP_KERNELVERSION packet)
in the LC_IDENT or LC_NOTE 'kern ver str' load command. In that
case, we should try to find the binary and dSYM for the UUID
listed. The dSYM may have python code which knows how to relocate
the binary to the correct address in lldb's target section load
list and loads other ancillary binaries.
The test case is a little involved,
1. it compiles an inferior hello world apple (a.out),
2. it compiles a program which can create a corefile manually
with a specific binary's UUID encoded in it,
3. it gets the UUID of the a.out binary,
4. it creates a shell script, dsym-for-uuid.sh, which will
return the full path to the a.out + a.out.dSYM when called
with teh correct UUID,
5. it sets the LLDB_APPLE_DSYMFORUUID_EXECUTABLE env var before
creating the lldb target, to point to this dsym-for-uuid.sh,
6. runs the create-corefile binary we compiled in step #2,
7. loads the corefile from step #6 into lldb,
8. verifies that lldb loaded a.out by reading the LC_NOTE
load command from the corefile, calling dsym-for-uuid.sh with
that UUID, got back the path to a.out and loaded it.
whew!
<rdar://problem/47562911>
llvm-svn: 366378
In ClangASTContext::CreateFunctionTemplateSpecializationInfo a TemplateArgumentList is allocated on the stack but is treated as if it is persistent in subsequent calls. When we exit the function func_decl will still point to the stack allocated memory. We will use TemplateArgumentList::CreateCopy instead which will allocate memory out of the DeclContext.
Differential Revision: https://reviews.llvm.org/D64777
llvm-svn: 366365
Disable colors so we don't risk having unexpected ANSI codes in the test
output. Currently, the behavior of a test can change depending on
whether it's run under a color-supporting terminal, or under a dummy
terminal, for example when using lit or multiprocessing.
llvm-svn: 366356
Summary:
With LLDB we use localUncachedLookup(), however, that fails to find
Decls when a transparent context is involved and the given DC has
external lexical storage. The solution is to use noload_lookup, which
works well with transparent contexts. But, we cannot use only the
noload_lookup since the slow case of localUncachedLookup is still needed
in some other cases.
These other cases are handled in ASTImporterLookupTable, but we cannot
use that with LLDB since that traverses through the AST which initiates
the load of external decls again via DC::decls().
We must avoid loading external decls during the import becuase
ExternalASTSource is implemented with ASTImporter, so external loads
during import results in uncontrolled and faulty import.
Reviewers: shafik, teemperor, jingham, clayborg, a_sidorin, a.sidorin
Subscribers: rnkovacs, dkrupp, Szelethus, gamesh411, cfe-commits, lldb-commits
Tags: #clang, #lldb
Differential Revision: https://reviews.llvm.org/D61333
llvm-svn: 366325
Summary:
It seems that calling Popen can return to the caller before the started process has read all the needed information
from its executable. This means that in case we delete the executable while the process is still starting up,
this test will create a zombie process which in turn leads to a failing test. On my macOS system this happens quite frequently.
This patch fixes this by letting the test synchronize with the inferior after it has started up.
Reviewers: davide
Reviewed By: davide
Subscribers: labath, friss, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D64546
llvm-svn: 365813
It seems on Windows we don't handle the lldb_expr_result variable correctly:
```
AssertionError: False is not True : 'expr $__lldb_expr_result' returns expected result, got '(int &) $0 = 0x0000000000000000'
```
I'll disable the test until I can find a way to debug this on Windows.
llvm-svn: 365719
Summary:
Fixed `Android.rules` for running test suite on remote android
- the build configuration is not compatible with ndk structure, change it to link to static libc++
- generally clang should be able to use libc++ and will link against the right library, but some libc++ installations require the user manually link libc++abi.
- add flag `-lc++abi` to fix the test binary build failure
Added `skipIfTargetAndroid` `skipUnlessTargetAndroid` for better test support
- the `skipIfPlatform` method will ask `lldbplatformutil.getPlatform()` for platform info which is actually the os type, and //Android// is not os type but environment
- create this function to handle the android target condition
**To Run Test on Remote Android**
1 start lldb-server on your devices
2 run lldb-dotest with following configuration:
`./lldb-dotest --out-of-tree-debugserver --arch aarch64 --platform-name remote-android --platform-url connect://localhost:12345 --platform-working-dir /data/local/tmp/ --compiler your/ndk/clang`
Reviewers: xiaobai, labath
Reviewed By: labath
Subscribers: labath, javed.absar, kristof.beyls, srhines, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D64118
llvm-svn: 365561
This test was originally marked as expected failure on Windows, but it is timing out instead of outright failing now. The expectedFailure attribute does not correctly track timeouts (as in, they don't count as failures), so now this is causing the test suite to fail.
llvm-svn: 365527
It looks like when this test was added, it was based on TestHelloWorld and it ended up with the same class name. This is an issue because the logs associated with the tests use the class name as the identifier for the file and if two tests have the same name their logs overwrite each other. On non-windows, this just means we lose one of the logs, but on Windows this means that one of the tests will fail occasionally because the file are locked by the other test.
llvm-svn: 364860
It looks like when this test was added, it was based on TestBreakAfterJoin and it ended up with the same class name. This is an issue because the logs associated with the tests use the class name as the identifier for the file and if two tests have the same name their logs overwrite each other. On non-windows, this just means we lose one of the logs, but on Windows this means that one of the tests will fail occasionally because the file are locked by the other test.
llvm-svn: 364826
Set global enable bits (i.e. bits 1, 3, 5, 7) to enable watchpoints
on NetBSD rather than the local enable bits (0, 2, 4, 6). The former
are necessary for watchpoints to be correctly recognized by the NetBSD
kernel. The latter cause them to be reported as trace points.
Differential Revision: https://reviews.llvm.org/D63792
llvm-svn: 364781
D62502, together with D62503 have broken the builds which have XML
support enabled. Reverting D62503 (r364355) fixed that, but has broken
has left some of the tests introduced by D62502 broken more or less
nondeternimistically (it depended on whether the system happens to place
the library list near unreadable pages of memory). I attempted to make a
partial fix for this in r364748, but Jan Kratochvil pointed out that
this reintroduces the problem which reverting D62503 was trying to
solve.
So instead, I back out the whole thing so we can get back to a clean
slate that works for everyone. We can figure out a way forward from
there.
This reverts r364748, r363772 and r363707.
llvm-svn: 364751
on a thread. When talking to some older gdb-remote stubs, We were getting
a stop reason from the stop reply packet and setting it on the relevant
thread before we updated the full stop list. That would get discarded when
the full list was updated.
Also, if you already have a thread list when you go to see if there is an
Operating System plugin, and you do indeed load a new OS plugin, you have to
re-fetch the thread list or it will only show the raw threads.
Differential Revision: https://reviews.llvm.org/D62887
llvm-svn: 364666
The qemu x86_64 target returns a target.xml register definition file which
includes other xml files and they include others, etc. Also, the registers
are not put in register groups like lldb wants to see.
This patch (1) puts registers that aren't in a register group in a "general"
register group, (2) change ProcessGDBRemote::GetGDBServerRegisterInfo to
be a method that starts the parsing, asking a recurisve function to fetch
and parse target.xml, (3) adds
ProcessGDBRemote::GetGDBServerRegisterInfoXMLAndProcess which can recusively
call itself to read and parse included xml files, (4) in addition to expecting
the top-level <target> element (which only happens in the top level xml file),
also an xml file that consists of a <feature> node - read the register
defintions and includes from that <feature> element.
<rdar://problem/49537922>
Differential revision: https://reviews.llvm.org/D63802
llvm-svn: 364484
This patch adds a dotest flag for setting environment variables for the
inferior. This is different from the current --env flag, which sets
variables in the debugger's environment. This allows us to set things
like LD_LIBRARY_PATH for testing.
Differential revision: https://reviews.llvm.org/D63790
llvm-svn: 364443
Summary:
Implement the ABI for WIndows-x86_64 including register info and calling convention.
Handled nested struct returned in register (SysV doesn't have it supported)
Reviewers: xiaobai, compnerd
Reviewed By: compnerd
Subscribers: labath, jasonmolenda, fedor.sergeev, mgorny, teemperor, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D62213
llvm-svn: 364216
on some systems this test fails because the two methods it uses to
cross-reference the data don't match in the case of the vdso module. The
"read from /proc/%pid/maps" method returns "[vdso]", while the method
which reads it from the linker rendezvous structures returns
"linux-vdso.so.1". Neither of the two names match any actual file.
This restricts the test to only consider the libraries that we ourselves
have added to the test, minimizing the impact of system dependencies
that we cannot control.
llvm-svn: 363772
Summary:
This is the fourth patch to improve module loading in a series that started here (where I explain the motivation and solution): D62499
Implement the `xfer:libraries-svr4` packet by adding a new function that generates the list and then in Handle_xfer I generate the XML for it. The XML is really simple so I'm just using string concatenation because I believe it's more readable than having to deal with a DOM api.
Reviewers: clayborg, xiaobai, labath
Reviewed By: labath
Subscribers: emaste, mgorny, srhines, krytarowski, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D62502
llvm-svn: 363707
Now that we correctly ignore ASCII escape sequences when colors are
disabled (r362240), I'd like to change the default frame and thread
format to include color in their output, in line with the syntax
highlighting that Raphael added a while ago.
This patch adds highlighting for the stop reason, the file, line and
column number. With colors disabled, this of course is a no-op.
Differential revision: https://reviews.llvm.org/D62743
llvm-svn: 363608
D55859 <https://reviews.llvm.org/D55859> has no effect for some of the
testcases so this patch extends it even for (all?) other testcases known to me.
LLDB was failing when LLDB prints errors reading system debug infos
(`*-debuginfo.rpm`, DWZ-optimized) which should never happen as LLDB testcases
should not be affected by system debug infos.
`lldb/packages/Python/lldbsuite/test/api/multithreaded/driver.cpp.template` is
using only SB API which does not expose `ModuleList` so I had to call
`HandleCommand()` there.
`lldb-test.cpp` could also use `HandleCommand` and then there would be no need
for `ModuleListProperties::SetEnableExternalLookup()` but I think it is cleaner
with API and not on based on text commands.
Differential Revision: https://reviews.llvm.org/D63339
llvm-svn: 363567
Skip watchpoint tests if security.models.extensions.user_set_dbregs
is disabled. This indicates that unprivileged processes are not allowed
to write to debug registers which is a prerequisite for using hardware
watchpoints.
Differential Revision: https://reviews.llvm.org/D63380
llvm-svn: 363536
Summary:
PersistentStateExpressions (e.g. ClangPersistentVariables) have the
ability to define types using expressions that persist throughout the
debugging session. GetCompilerTypeFromPersistentDecl is a useful
operation to have if you need to use any of those persistently declared types,
like in CommandObjectMemory.
This decouples clang from CommandObjectMemory and decouples Plugins from
Commands in general.
Differential Revision: https://reviews.llvm.org/D62797
llvm-svn: 363183
Add a function to flatten the nested aggregate type
Differential Revision: https://reviews.llvm.org/D62702
Patch by Wanyi Ye <kusmour@gmail.com>
llvm-svn: 362543
This fixes an unintended regression introduced by
https://reviews.llvm.org/D61451 by making sure the Objective-C runtime
is also tried when the "correct" language runtime failed to return an
object description.
rdar://problem/50791055
Differential Revision: https://reviews.llvm.org/D62015
llvm-svn: 360929
Summary:
I don't think there's a good reason for this behavior to be considered
ObjC-specific. We can generalize this.
Differential Revision: https://reviews.llvm.org/D61776
llvm-svn: 360741
Replace checked-in minidumps with their yaml forms now that yaml2obj
supports the ThreadList stream. I delete the test_modules_in_mini_dump
test altogether as this functionality is covered more systematically in
TestMinidumpUUID.py.
llvm-svn: 360655
logging when the testsuite is run with trace mode enabled are leaving
the logging enabled after the tests have finished. That state
isn't cleared in a --no-multiprocess testsuite run.
llvm-svn: 360480
This can cause us to return paths to files on the local filesystem even
if we don't end up using that file (for instance because the file is not
a real module).
llvm-svn: 360432
While this fixed the windows bot failures, it also broke all other bots.
Upon closer inspection, it turns out that the windows bots were "broken"
because two tests were unexpectedly passing -- i.e., the original patch
(r360375) actually improved our stepping support on windows.
So instead, I remove the relevant XFAILs.
This reverts commit r360397.
llvm-svn: 360407
Currently when we single step over a source line, we run and stop at every branch in the source line range. We can reduce the number of times we stop when stepping over by figuring out if any of these branches are function calls, and if so, ignore these branches. Since we are stepping over we can safely ignore these calls since they will return to the next instruction. Currently the step logic would stop at those branches (1st stop), single step into the branch (2nd stop), and then set a breakpoint at the return address (3rd stop), and then continue.
Differential Revision: https://reviews.llvm.org/D58678
llvm-svn: 360375
The test is failing sometimes because the debugger is failing to attach for lack of permissions. The fix is to call lldb_enable_attach inside the inferior main function
llvm-svn: 360371
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
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
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
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
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
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
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
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
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
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
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
