Summary:
This was causing problems on linux, where we'd end up calling the
deleting destructor instead of a regular one (because they have the same
demangled name), making a lot of mischief in the process.
The only place where this was necessary (according to the test suite, at
least) was to call a base structor instead of a complete one, but this
is now handled in a more targeted fashion.
TestCallOverriddenMethod is now re-enabled as it now passes reliably.
Reviewers: teemperor, JDevlieghere
Subscribers: lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D70722
I have either opened new bug reports for these tests, or added links to
existing bugs.
This should help make the lldb-aarch64-ubuntu buildbot green (there will
still be some unexpected passes that someone should look into, but those
can be handled later).
NetBSD ptrace interface does not populate watchpoints to newly-created
threads. Solve this via copying the watchpoints from the current thread
when new thread is reported via TRAP_LWP.
Add a test that verifies that when the user does not have permissions
to set watchpoints on NetBSD, the 'watchpoint set' errors out gracefully
and thread monitoring does not crash on being unable to copy watchpoints
to new threads.
Differential Revision: https://reviews.llvm.org/D70023
Implement major improvements to multithreaded program support. Notably,
support tracking new and exited threads, associate signals and events
with correct threads and support controlling individual threads when
resuming.
Firstly, use PT_SET_EVENT_MASK to enable reporting of created and exited
threads via SIGTRAP. Handle TRAP_LWP events to keep track
of the currently running threads.
Secondly, update the signal (both generic and SIGTRAP) handling code
to account for per-thread signals correctly. Signals delivered
to the whole process are reported on all threads, while per-thread
signals and events are reported only to the specific thread.
The remaining threads are marked as 'stopped with no reason'. Note that
NetBSD always stops all threads on debugger events.
Thirdly, implement the ability to set every thread as running, stopped
or single-stepping separately while continuing the process. This also
provides the ability to send a signal to the whole process or to one
of its thread while resuming.
Differential Revision: https://reviews.llvm.org/D70022
Summary:
To run the testsuite remotely the executable needs to be uploaded to
the target system. The Target takes care of this by default.
When the test uses additional shared libraries, those won't be handled
by default and need to be registered with the target using
test.registerSharedLibrariesWithTarget(target, dylib).
Calling this API requires a target, so it doesn't mesh well with the
run_to_* helpers that we've been advertising as the right way to write
tests.
This patch adds an extra_images argument to all the helpers and does
the registration automatically when running a remote
testsuite. TestWeakSymbols.py was converted to use this new scheme.
Reviewers: jingham
Subscribers: lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D70134
TestFormatters.py has a sequence of three 'next' commands to get past
all the initializations in the test function. On AArch64 (and
potentially other platforms), this was one 'next' too many and we ended
up outside our frame.
This patch replaces the sequence with a 'thread until ' the line of the
return from the function, so we should stop after all the
initializations but before actually returning.
Differential Revision: https://reviews.llvm.org/D70303
The function call and the constructor call fail now several Linux
bots (Swift CI, my own bot and Stella's Debian system), so let's disable
the relevant test parts until we can figure out why it is failing.
Summary: This option was added downstream in swift-lldb. This upstreams this option as it seems useful and also adds the missing tests.
Reviewers: #lldb, kwk, labath
Reviewed By: kwk, labath
Subscribers: labath, kwk, abidh, JDevlieghere, lldb-commits
Tags: #lldb, #upstreaming_lldb_s_downstream_patches
Differential Revision: https://reviews.llvm.org/D69944
Add info for all register sets supported in NetBSD, particularly for all
registers 'expected' by LLDB. This is necessary in order to fix
python_api/lldbutil/iter/TestRegistersIterator.py test that currently
fails due to missing names of register sets (None).
This copies fpreg descriptions from Linux, and combines Linux' AVX
and MPX registers into a single XState group, to fit NetBSD register
group design. Technically, we do not support MPX registers
at the moment but gdb-remote insists on passing their errors anyway,
and if we do not include it in any group, they end up in a separate
anonymous group that breaks the test.
While at it, swap the enums for XState and DBRegs to match register set
ordering.
This also adds a few consts to the lldb-x86-register-enums.h to provide
more consistency between user registers and debug registers.
Differential Revision: https://reviews.llvm.org/D69667
Summary:
This change increases the offset of MPX registers (by 128) so they
do not overlap with the offset associated with AVX registers. That was
causing MPX data in GDBRemoteRegisterContext::m_reg_data to get overwritten.
Reviewers: labath
Reviewed By: labath
Subscribers: JDevlieghere, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D68874
Summary:
So far we rely on the default argument and the fact that we don't call this
inline function in our actual `main.cpp` to make sure that this function can only
be called if LLDB loads this header as a C++ module. This patch just adds
the nodebug attribute as yet another measure to make sure LLDB can't call this
function without the standard module loaded. Note that the test is already
requiring clang for the sysroot setup, so its fine that this is a Clang specific attribute.
Reviewers: friss, labath
Subscribers: JDevlieghere, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D68861
Summary:
This patch converts another user of ArgInfo::count over to
use ArgInfo::max_positional_args instead. I also add a test
to make sure both documented signatures for python type formatters
work.
Reviewers: JDevlieghere, clayborg, labath, jingham
Reviewed By: labath
Subscribers: lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D69153
llvm-svn: 375334
Summary:
When users define a debugger command from python, they provide a callable
object. Because the signature of the function has been extended, LLDB
needs to inspect the number of parameters the callable can take.
The rule it was using to decide was weird, apparently not tested, and
giving wrong results for some kinds of python callables.
This patch replaces the weird rule with a simple one: if the callable can
take 5 arguments, it gets the 5 argument version of the signature.
Otherwise it gets the old 4 argument version.
It also adds tests with a bunch of different kinds of python callables
with both 4 and 5 arguments.
Reviewers: JDevlieghere, clayborg, labath, jingham
Reviewed By: labath
Subscribers: lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D69014
llvm-svn: 375333
We call these tests in the second test function where they are
x-failed on Windows. I forgot to remove the tests from the first
test function (which is not x-failed on Windows) when extracting these
calls into their own test function, so the test is still failing on Windows.
llvm-svn: 375271
These tests were testing a bug related to constructors. It seems that
on Windows the expression command can't construct objects (or at least,
call their constructor explicitly which is required for the tests), so
this is just x-failing them until Windows actually supports constructor calls.
llvm-svn: 375173
Summary:
When we have a artificial constructor DIE, we currently create from that a global function with the name of that class.
That ends up causing a bunch of funny errors such as "must use 'struct' tag to refer to type 'Foo' in this scope" when
doing `Foo f`. Also causes that constructing a class via `Foo()` actually just calls that global function.
The fix is that when we have an artificial method decl, we always treat it as handled even if we don't create a CXXMethodDecl
for it (which we never do for artificial methods at the moment).
Fixes rdar://55757491 and probably some other radars.
Reviewers: aprantl, vsk, shafik
Reviewed By: aprantl
Subscribers: jingham, shafik, labath, JDevlieghere, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D68130
llvm-svn: 375151
Summary: `platform process list -v` on windows doesn't show all the process arguments, making this test useless for that platform
Reviewers: stella.stamenova
Subscribers: lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D69114
llvm-svn: 375144
We essentially test libc++ in a sysroot here so let's make sure
that we actually only run this test on platforms where libc++
testing is enabled.
llvm-svn: 374572
We currently don't handle the error in the Expected we get
when searching for an equal local DeclContext. Usually this can't
happen as this would require that we have a STL container and
we can find libc++'s std module, but when we load the module in
the expression parser the module doesn't even contain the 'std'
namespace. The only way I see to test this is by having a fake
'std' module that requires a special define to actually provide
its contents, while it will just be empty (that is, it doesn't
even contain the 'std' namespace) without that define. LLDB currently
doesn't know about that define in the expression parser, so it
will load the wrong 'empty' module which should trigger this error.
Also removed the 'auto' for that variable as the function name
doesn't make it obvious that this is an expected and not just
a optional/ptr (which is how this slipped in from the start).
llvm-svn: 374525
This test was previously passing because myabs was actually emitted into the
debug information and we called that. The test itself was broken as it didn't
use the libc++ directory structure (the /v1/ directory was just called /include/).
This patch gives myabs a default argument which we can't get from debug information
and inlines the function to make sure we can't call it from LLDB without loading
the C++ module.
llvm-svn: 374335
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
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
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
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
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
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
