Summary: The test logic for running libc++ tests only looks to see if `/usr/include/c++/v1` exists. This adds a fallback for including libc++ tests as long as `$(CC) -stdlib=libc++` works.
Reviewers: labath, EricWF
Subscribers: ldionne, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D71319
I don't think this test case can be handled correctly on AAPCS64.
The ABI says that the caller passes the address of the return object
in x8. x8 is a caller-spilled (aka "volatile") register, and the
function is not required to preserve x8 or to copy the address back
into x8 on function exit like the SysV x86_64 ABI does with rax.
(from aapcs64: "there is no requirement for the callee to preserve the
value stored in x8")
From my quick reading of ABISysV_arm64, I worry that it may actually be
using the value in x8 at function exit, assuming it still has the
address of the return object -
if (is_return_value) {
// We are assuming we are decoding this immediately after returning from
// a function call and that the address of the structure is in x8
reg_info = reg_ctx->GetRegisterInfoByName("x8", 0);
This will work on trivial test programs / examples, but if the function
does another function call, or overwrites x8 as a scratch register, lldb
will provide incorrect values to the user.
ABIMacOSX_arm64 doesn't do this, but it also doesn't flag the value
as unavailable so we're providing incorrect values to the user all
the time. I expect my fix will be to make ABIMacOSX_arm64 flag
the return value as unretrievable, unless I've misread the ABI.
of depending on it being set in the environment. Fred's change
from October assumed that SDKROOT was set in the environment
so that 'xcrun --show-sdk-path' would print the path. If it
was passed in as a Makefile variable, it wouldn't be set in
the environment and xcrun --show-sdk-path would always show the
macOS SDK path. When running the lldb testsuite against an ios
device via lit, this seems to be the case.
The cache in FormatCache uses only a type name as key. The hardcoded
formats, synthetic children, etc inspect an entire ValueObject to
determine their eligibility, which isn't modelled in the cache. This
leads to bugs such as the one in this patch (where two similarly named
types in different files have different hardcoded summary
providers). The problem is exaggerated in the Swift language plugin
due to the language's dynamic nature.
rdar://problem/57756763
Differential Revision: https://reviews.llvm.org/D71233
Summary:
Our Editline implementation in LLDB supports using the wchar interface of Editline which
should improve handling of unicode input when using Editline. At the moment we essentially
just ignore unicode input and echo the escaped unicode code point (`\U1234`) to the command line
(which we then also incorrectly treat as multiple characters, so console navigation is also broken afterwards).
This patch just adds the include to the host config file which already contains the LLDB_EDITLINE_USE_WCHAR
define to enable the Editline support (we just never included it in the file before). With this we now actually
echo back unicode characters on macOS and we no longer ignore unicode input. On Linux this doesn't
seem to improve the echoing back of characters but at least it fixes that we ignore unicode input.
Reviewers: labath
Reviewed By: labath
Subscribers: JDevlieghere, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D71251
"The debug adapter supports the delayed loading of parts of the stack,
which requires that both the 'startFrame' and 'levels' arguments and the
'totalFrames' result of the 'StackTrace' request are supported."
Lack of this field makes VSCode incorrectly display stack traces information
D71034
This test was accidentally passing on non-darwin OS because it was
explicitly setting the CFLAGS make variable. This meant that (in the
default config) it was building with absolutely no debug info, and so
setting a breakpoint on a stripped symbol failed, because there was
really no trace of it remaining. In other configurations, we were
generating the debug info (-gsplit-dwarf implies -g) and the test failed
because we did not treat the zeroed out debug info address specially.
The test was also xfailed in pretty much every non-standard
configuration.
This patch fixes the makefile to avoid messing with CFLAGS (use
CFLAGS_EXTRAS instead). This causes it to fail in all configurations
(except darwin), and so I replace the various decorators with a simple
os!=darwin check.
Summary:
One of the ways we try to make LLDB faster is by only creating the Clang declarations (and loading the associated types)
when we actually need them for something. For example an evaluated expression might need to load types to
type check and codegen the expression.
Currently this mechanism isn't really tested, so we currently have no way to know how many Clang nodes we load and
when we load them. In general there seems to be some confusion when and why certain Clang nodes are created.
As we are about to make some changes to the code which is creating Clang AST nodes we probably should have
a test that at least checks that the current behaviour doesn't change. It also serves as some kind of documentation
on the current behaviour.
The test in this patch is just evaluating some expressions and checks which Clang nodes are created due to this in the
module AST. The check happens by looking at the AST dump of the current module and then scanning it for the
declarations we are looking for.
I'm aware that there are things missing in this test (inheritance, template parameters, non-expression evaluation commands)
but I'll expand it in follow up patches.
Also this test found two potential bugs in LLDB which are documented near the respective asserts in the test:
1. LLDB seems to always load all types of local variables even when we don't reference them in the expression. We had patches
that tried to prevent this but it seems that didn't work as well as it should have (even though we don't complete these
types).
2. We always seem to complete the first field of any record we run into. This has the funny side effect that LLDB is faster when
all classes in a project have an arbitrary `char unused;` as their first member. We probably want to fix this.
Reviewers: shafik
Subscribers: abidh, JDevlieghere, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D71056
Summary:
When creating a test with `lldbinline.MakeInlineTest()`, the reported `inspect.getfile(test.__class__)` is `lldbtest.pyc`, meaning any `.categories` file will be ineffective for those tests. Check for the test_filename first, which inline tests will set.
Additionally, raise an error with the starting dir if `.categories` is not found. This makes the problem more obvious when it occurs: when the test is separated from the test framework tree.
Reviewers: labath, JDevlieghere
Subscribers: lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D71099
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
This replaces `include $(LEVEL)/Makefile.rules` with `include Makefile.rules`.
The lldb test driver already passes the include path when running make, and specifically looking for "../../Makefile.rules" forces the test to be in a specific location.
Removing this hardcoded relative path will make it possible to move this test as-is.
options class. This value was hanging around so for instance if you made a scripted breakpoint
resolver, then went to set another breakpoint, it would still think you had passed in a class
name and the breakpoint wouldn't do what you expected.
Summary:
Using a BreakpointList corrupts the breakpoints' IDs because
BreakpointList::Add sets the ID, so use a vector instead, and
update the signature to return the vector wrapped in an
llvm::Expected which can propagate any error from the inner
call to StringIsBreakpointName.
Note that, despite the similar name, SBTarget::FindBreakpointsByName
doesn't suffer the same problem, because it uses a SBBreakpointList,
which is more like a BreakpointIDList than a BreakpointList under the
covers.
Add a check to TestBreakpointNames that, without this fix, notices the
ID getting mutated and fails.
Reviewers: jingham, JDevlieghere
Reviewed By: JDevlieghere
Subscribers: lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D70907
I assumed this was just a single typo, but it seems we actually have
a whole bunch of tabs in this file which cause Python to complain
about mixing tabs and spaces.
Mixing tabs and spaces makes Python exit with this error:
File "llvm/lldb/packages/Python/lldbsuite/test/functionalities/return-value/TestReturnValue.py", line 23
return (self.getArchitecture() == "aarch64" and self.getPlatform() == "linux")
^
TabError: inconsistent use of tabs and spaces in indentation
Summary:
Previously the ABI plugin exposed some "register infos" and the
gdb-remote code used those to fill in the missing bits. Now, the
"filling in" code is in the ABI plugin itself, and the gdb-remote code
just invokes that.
The motivation for this is two-fold:
a) the "augmentation" logic is useful outside of process gdb-remote. For
instance, it would allow us to avoid repeating the register number
definitions in minidump code.
b) It gives more implementation freedom to the ABI classes. Now that
these "register infos" are essentially implementation details, classes
can use other methods to obtain dwarf/eh_frame register numbers -- for
instance they can consult llvm MC layer.
Since the augmentation code was not currently tested anywhere, I took
the opportunity to create a simple test for it.
Reviewers: jasonmolenda, clayborg, tatyana-krasnukha
Subscribers: aprantl, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D70906
The idea is to remove front-end analysis for the parameter's value
modification and leave it to the value tracking system. Front-end in some
cases marks a parameter as modified even the line of code that modifies the
parameter gets optimized, that implies that this will cover more entry
values even. In addition, extending the support for modified parameters
will be easier with this approach.
Since the goal is to recognize if a parameter’s value has changed, the idea
at very high level is: If we encounter a DBG_VALUE other than the entry
value one describing the same variable (parameter), we can assume that the
variable’s value has changed and we should not track its entry value any
more. That would be ideal scenario, but due to various LLVM optimizations,
a variable’s value could be just moved around from one register to another
(and there will be additional DBG_VALUEs describing the same variable), so
we have to recognize such situation (otherwise, we will lose a lot of entry
values) and salvage the debug entry value.
Differential Revision: https://reviews.llvm.org/D68209
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).
Summary:
This test was broken in two ways:
* Using the wrong API (e.g.: format = instead of SetFormat)
* The hex checker was only checking "01" which will pass with 0x0000001
Reviewers: clayborg, lanza, wallace
Reviewed By: clayborg
Subscribers: lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D70884
This reapplies: 8ff85ed905
Original commit message:
As a follow-up to my initial mail to llvm-dev here's a first pass at the O1 described there.
This change doesn't include any change to move from selection dag to fast isel
and that will come with other numbers that should help inform that decision.
There also haven't been any real debuggability studies with this pipeline yet,
this is just the initial start done so that people could see it and we could start
tweaking after.
Test updates: Outside of the newpm tests most of the updates are coming from either
optimization passes not run anymore (and without a compelling argument at the moment)
that were largely used for canonicalization in clang.
Original post:
http://lists.llvm.org/pipermail/llvm-dev/2019-April/131494.html
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D65410
This reverts commit c9ddb02659.
Fix handling concurrent watchpoint events so that they are reported
correctly in LLDB.
If multiple watchpoints are hit concurrently, the NetBSD kernel reports
them as series of SIGTRAPs with a thread specified, and the debugger
investigates DR6 in order to establish which watchpoint was hit. This
is normally fine.
However, LLDB disables and reenables the watchpoint on all threads after
each hit, which results in the hit status from DR6 being wiped.
As a result, it can't establish which watchpoint was hit in successive
SIGTRAP processing.
In order to workaround this problem, clear DR6 only if the breakpoint
is overwritten with a new one. More specifically, move cleaning DR6
from ClearHardwareWatchpoint() to SetHardwareWatchpointWithIndex(),
and do that only if the newly requested watchpoint is different
from the one being set previously. This ensures that the disable-enable
logic of LLDB does not clear watchpoint hit status for the remaining
threads.
This also involves refactoring of watchpoint logic. With the old logic,
clearing watchpoint involved wiping dr6 & dr7, and setting it setting
dr{0..3} & dr7. With the new logic, only enable bit is cleared
from dr7, and the remaining bits are cleared/overwritten while setting
new watchpoint.
Differential Revision: https://reviews.llvm.org/D70025
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:
The test used a non-stopping "run" command to launch the process. This
is different from the regular launch with no extra launch commands,
which uses eLaunchFlagStopAtEntry to ensure that the process stops
straight away.
I'm not really sure what's supposed to happen in non-stop-at-entry mode,
or if that's even supported, but what ended up happening was the launch
packet got a reply while the process was running. Then the test case did
a continue_to_next_stop(), which queued a *second* resume request
(along with the internal "resumes" which were being issued as a part of
normal process startup). These two resumes ended up chasing each other's
tails inside lldb in a way which produced hilarious log traces.
Surprisingly, the test ended up passing most of the time, but it did
cause spurious failures when the test seemed to miss a breakpoint.
This changes the test to use stop-at-entry mode in the manual launch
sequence too, which seems to be enough to make the test pass reliably.
Reviewers: clayborg, kusmour, jankratochvil
Subscribers: lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D70127
Split CallEdge into DirectCallEdge and IndirectCallEdge. Teach
DWARFExpression how to evaluate entry values in cases where the current
activation was created by an indirect call.
rdar://57094085
Differential Revision: https://reviews.llvm.org/D70100
This affects -gmodules only.
Under normal operation pcm_type is a shallow forward declaration
that gets completed later. This is necessary to support cyclic
data structures. If, however, pcm_type is already complete (for
example, because it was loaded for a different target before),
the definition needs to be imported right away, too.
Type::ResolveClangType() effectively ignores the ResolveState
inside type_sp and only looks at IsDefined(), so it never calls
ClangASTImporter::ASTImporterDelegate::ImportDefinitionTo(),
which does extra work for Objective-C classes. This would result
in only the forward declaration to be visible.
An alternative implementation would be to sink this into Type::ResolveClangType ( 88235812a7/lldb/source/Symbol/Type.cpp (L5809)) though it isn't clear to me how to best do this from a layering perspective.
rdar://problem/52134074
Differential Revision: https://reviews.llvm.org/D70415
Summary: Ensure that breakpoint ivar is properly set in exception breakpoint resolver so that exception breakpoints set on dummy targets are resolved once real targets are created and run.
Reviewers: jingham
Reviewed By: jingham
Subscribers: teemperor, JDevlieghere, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D69880
lldb would silently accept a response to the 'g' packet
(read all registers) which was too large; this handles the
case where it is too small.
Differential Revision: https://reviews.llvm.org/D70417
<rdar://problem/34916465>
It turns out that the ExprMutationAnalyzer can be very slow when AST
gets huge in some cases. The idea is to move this analysis to the LLVM
back-end level (more precisely, in the LiveDebugValues pass). The new
approach will remove the performance regression, simplify the
implementation and give us front-end independent implementation.
Differential Revision: https://reviews.llvm.org/D68206
Summary:
expect() forwards its command to sendline(). This can be problematic if the command already contains a newline: sendline() unconditionally adds a newline to the command, which causes the command to run twice (hitting enter in lldb runs the previous command). The expect() helper looks for the prompt and finds the first one, but because the command has run a second time, the buffer will contain the contents of the second time the command ran, causing potential erroneous matching.
Simplify the editline test, which was using different commands to workaround this misunderstanding.
Reviewers: labath
Reviewed By: labath
Subscribers: merge_guards_bot, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D70324
I just used the mangled names as this test is anyway a Darwin-only ObjC++ test.
We probably should also test this on other platforms but that will be
another commit as we need to untangle the ObjC and C++ parts first.
These tests are failing with various assertion failures, but they all
throw the following error message first:
error: a.out 0x0000002d: adding range [0x14-0x24) which has a base that
is less than the function's low PC 0x40060c.
See llvm.org/pr44037.
Differential Revision: https://reviews.llvm.org/D70381
Implement thread name getting sysctl() on NetBSD. Also fix
the incorrect type in pthread_setname_np() in the relevant test.
Differential Revision: https://reviews.llvm.org/D70363
Summary:
The DAP has a completion request that has been unimplemented. It allows showing autocompletion tokens inside the Debug Console.
I implemented it in a very simple fashion mimicking what the user would see when autocompleting an expression inside the CLI.
There are two cases: normal variables and commands. The latter occurs when a text is prepepended with ` in the Debug Console.
These two cases work well and have tests.
Reviewers: clayborg, aadsm
Subscribers: lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D69873
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
This feature is mostly there to aid debugging of Clang module issues,
since the only useful actual the end-user can to is to recompile their
program.
Differential Revision: https://reviews.llvm.org/D70272
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
Summary:
This adds several 5C/5D escape codes that allow moving forward/backward words similar to bash command line navigation.
On my terminal, `ctrl+v ctrl+<left arrow>` prints `^[[1;5D`. However, it seems inputrc also maps other escape variants of this to forward/backward word, so I've included those too. Similar for 5C = ctrl+right arrow.
Reviewers: JDevlieghere, labath
Reviewed By: JDevlieghere, labath
Subscribers: merge_guards_bot, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D70137
This patch fixes whitespace/tabs mismatch in
lldb/packages/Python/lldbsuite/test/make/Makefile.rules
Legacy make files always used tabs though modern make version can
work with white-spaces I have chosen the legacy just to be safe.
Signed-off-by: Muhammad Omair Javaid <omair.javaid@linaro.org>
Differential Revision: https://reviews.llvm.org/D70154
This patch adds core definitions in lldb ArchSpecs for armv8l and armv7l cores.
This was needed because on Linux running on 32-bit Arm v8 we are returned
armv8l in case we are running 32-bit sysroot on 64bit kernel. In case of 32-bit
kernel and 32-bit sysroot running on arm v8 hardware we are returned armv7l.
This is quite common when we run 32 bit arm using docker container.
Signed-off-by: Muhammad Omair Javaid <omair.javaid@linaro.org>
Differential Revision: https://reviews.llvm.org/D69904
Performance issues lead to the libc++ std::function formatter to be disabled. We addressed some of those performance issues by adding caching see D67111
This PR fixes the first lookup performance by not using FindSymbolsMatchingRegExAndType(...) and instead finding the compilation unit the std::function wrapped callable should be in and then searching for the callable directly in the CU.
Differential Revision: https://reviews.llvm.org/D69913
The VSCode tests were all disabled on macOS because the implementation
had some issues that resulted in flakiness on Darwin. It seems most of
these issues have been addressed. I've re-enabled all the tests that
consistently passed locally.
When we switched to the LLVM .debug_line parser, the .dSYM-style path
remapping logic stopped working for relative paths because of how
RemapSourceFile silently fails for relative paths. This patch both
makes the code more readable and fixes this particular bug.
One interesting thing I learned is that Module::RemapSourceFile() is a
macOS-only code path that operates on on the lldb::Module level and is
completely separate from target.source-map, which operates on a
per-Target level.
Differential Revision: https://reviews.llvm.org/D70037
rdar://problem/56924558
The mock server pretends the process stopped with signal 17, which is
SIGCHLD on linux. This causes lldb to resume to process, utterly
confusing the test. Lldb probably shouldn't resume in this case, but for
now this issue can be fixed by changing the signal number to 2, which is
SIGINT just about anywhere.
until we can automatically fall back to p/P if g/G are not supported;
it looks like there is a bug in debugserver's g/G packets taht needs
to be fixed, or debugserver should stop supporting g/G until that bug
is fixed. But we need lldb to be able to fall back to p/P correctly
for that to be a viable workaround.
and that lldb uses the expedited register values in the ? packet
aka stop packet (T11 etc) and does not re-fetch them with the p packet.
This test is currently failing from the "[lldb-server] Add setting to
force 'g' packet use" commit; I'm marking it as @expectedFailureAll
until we can get this fixed.
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
Following up on https://reviews.llvm.org/D62221, this change introduces
the settings plugin.process.gdb-remote.use-g-packet-for-reading. When
they are on, 'g' packets are used for reading registers.
Using 'g' packets can improve performance by reducing the number of
packets exchanged between client and server when a large number of
registers needs to be fetched.
Differential revision: https://reviews.llvm.org/D62931
Performance issues lead to the libc++ std::function formatter to be disabled.
This change is the first of two changes that should address the performance issues and allow us to enable the formatter again.
In some cases we end up scanning the symbol table for the callable wrapped by std::function for those cases we will now cache the results and used the cache in subsequent look-ups. This still leaves a large cost for the initial lookup which will be addressed in the next change.
Differential Revision: https://reviews.llvm.org/D67111
To do so, we need to register the sanitizer libraries with the target
so that they get uploaded before running. This patch adds a helper to
the test class to this effect.
If you are running on macOS and have the CommandLineTools installed of
Xcode, this test will fail because CommandLineTools doesn't ship with
libMainThreadChecker. Skip the test if you don't have it installed.
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:
I don't see why this test needs to compile this rather complicated file for just testing module sections. This just removes all this code with a simple
"Hello world!" program which should be faster to compile
Reviewers: labath, davide, JDevlieghere
Reviewed By: JDevlieghere
Subscribers: jfb, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D69705
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:
It is inherently unsafe to allow a python program to manipulate borrowed
memory from a python object's destructor. It would be nice to
flush a borrowed file when python is finished with it, but it's not safe
to do on python 2.
Python 3 does not suffer from this issue.
Reviewers: labath, mgorny
Reviewed By: labath
Subscribers: lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D69532
The architecture enum contains two kinds of contstants: the "official" ones
defined by Microsoft, and unofficial constants added by breakpad to cover the
architectures not described by the first ones.
Up until now, there was no big need to differentiate between the two. However,
now that Microsoft has defined
https://docs.microsoft.com/en-us/windows/win32/api/sysinfoapi/ns-sysinfoapi-system_info
a constant for ARM64, we have a name clash.
This patch renames all breakpad-defined constants with to include the prefix
"BP_". This frees up the name "ARM64", which I'll re-introduce with the new
"official" value in a follow-up patch.
Reviewers: amccarth, clayborg
Subscribers: lldb-commits, llvm-commits
Differential Revision: https://reviews.llvm.org/D69285
Summary:
Move breakpoints from the old, bad ArgInfo::count to the new, better
ArgInfo::max_positional_args. Soon ArgInfo::count will be no more.
It looks like this functionality is already well tested by
`TestBreakpointCommandsFromPython.py`, so there's no need to write
additional tests for it.
Reviewers: labath, jingham, JDevlieghere
Reviewed By: labath
Subscribers: lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D69468
Summary:
Here's another instance where we were calling fflush on an input
stream, which is illegal on NetBSD.
Reviewers: labath, mgorny
Reviewed By: mgorny
Subscribers: krytarowski, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D69488
This test was timing out on the swift CI bots. I didn't see any obvious reason
for that, and the test hasn't had problems on greendragon. OTOH, it was a bit
oddly written, and needed modernizing, so I did that.
Differential Revision: https://reviews.llvm.org/D69453
Summary:
We add support for DW_AT_export_symbols to detect anonymous struct on top of the heuristics implemented in D66175
This should allow us to differentiate anonymous structs and unnamed structs.
We also fix TestTypeList.py which was incorrectly detecting an unnamed struct as an anonymous struct.
Differential Revision: https://reviews.llvm.org/D68961
The invocation shown by dotest.py to re-run a single test is misleading:
it ranges from missing arguments (best case scenario) to being totally
wrong (worst case scenario).
In the past I've tried to get it right, but given the dotest
architecture this is harder than it looks. Furthermore, we have pretty
good documentation on the website [1] for most use cases.
This patch removes the rerun invocation.
[1] https://lldb.llvm.org/resources/test.html
For example, it is pretty easy to write a breakpoint command that implements "stop when my caller is Foo", and
it is pretty easy to write a breakpoint command that implements "stop when my caller is Bar". But there's no
way to write a generic "stop when my caller is..." function, and then specify the caller when you add the
command to a breakpoint.
With this patch, you can pass this data in a SBStructuredData dictionary. That will get stored in
the PythonCommandBaton for the breakpoint, and passed to the implementation function (if it has the right
signature) when the breakpoint is hit. Then in lldb, you can say:
(lldb) break com add -F caller_is -k caller_name -v Foo
More generally this will allow us to write reusable Python breakpoint commands.
Differential Revision: https://reviews.llvm.org/D68671
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
Summary:
The minidump exception stream can report an exception record with
signal 0. If we try to create a stop reason with signal zero, processing
of the stop event won't find anything, and the debugger will hang.
So, simply early-out of RefreshStateAfterStop in this case.
Also set the UnixSignals object in DoLoadCore as is done for
ProcessElfCore.
Reviewers: labath, clayborg, jfb
Reviewed By: labath, clayborg
Subscribers: dexonsmith, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D68096
llvm-svn: 375244
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
Summary:
ScriptInterpreterPython needs to save and restore sys.stdout and
friends when LLDB runs a python script.
It currently does this using FILE*, which is not optimal. If
whatever was in sys.stdout can not be represented as a FILE*, then
it will not be restored correctly when the script is finished.
It also means that if the debugger's own output stream is not
representable as a file, ScriptInterpreterPython will not be able
to redirect python's output correctly.
This patch updates ScriptInterpreterPython to represent files with
lldb_private::File, and to represent whatever the user had in
sys.stdout as simply a PythonObject.
This will make lldb interoperate better with other scripts or programs
that need to manipulate sys.stdout.
Reviewers: JDevlieghere, jasonmolenda, labath
Reviewed By: labath
Subscribers: lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D68962
llvm-svn: 374964
Summary:
This patch removes FILE* and replaces it with SBFile and FileSP the
SWIG interface for `SBStream.i`. And this is the last one. With
this change, nothing in the python API will can access a FILE* method
on the C++ side.
Reviewers: JDevlieghere, jasonmolenda, labath
Reviewed By: labath
Subscribers: lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D68960
llvm-svn: 374924
Summary:
This patch converts the swig wrappers for SetInputFileHandle() and friends
to emulate the old behavior using SetInputFile().
This will clear the way for deleting the FILE* typemaps altogether.
Reviewers: JDevlieghere, jasonmolenda, labath
Reviewed By: labath
Subscribers: mehdi_amini, dexonsmith, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D68856
llvm-svn: 374912
Summary:
This makes SBFile::GetFile public and adds a SWIG typemap to convert
the result back into a python native file.
If the underlying File itself came from a python file, it is returned
identically. Otherwise a new python file object is created using
the file descriptor.
Reviewers: JDevlieghere, jasonmolenda, labath
Reviewed By: labath
Subscribers: lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D68737
llvm-svn: 374911
- use a full triple instead of just the architecture (makes the test
pass on non-apple hosts)
- skip the test if the ARM llvm target is not built
llvm-svn: 374863
Summary:
This patch replaces the FILE* python bindings for SBInstruction and
SBInstructionList and replaces them with the new, safe SBFile and FileSP
bindings.
I also re-enable `Test_Disassemble_VST1_64`, because now we can use
the file bindings as an additional test of the disassembler, and we
can use the disassembler test as a test of the file bindings.
The bugs referred to in the comments appear to have been fixed. The
radar is closed now and the bugzilla bug does not reproduce with the
instructions given.
Reviewers: JDevlieghere, jasonmolenda, labath
Reviewed By: labath
Subscribers: lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D68890
llvm-svn: 374820
Summary:
This patch adds FileSP and SBFile versions of the API methods
ReportEventState and HandleProcessEvent. It points the SWIG
wrappers at these instead of the ones that use FILE* streams.
Reviewers: JDevlieghere, jasonmolenda, labath, jingham
Reviewed By: labath
Subscribers: lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D68546
llvm-svn: 374816
Summary:
The build directory name is based on the test method name, so having
two test methods with the same name in the same test file is a
problem, even if they're in different test classes.
On linux and darwin this conflict can go unnoticed, but windows
has different filesystem semantics and it will fail when one
process tries to delete files still held open by another.
The problem is fixed just by changing the name of one of the test
methods.
Reviewers: JDevlieghere, jasonmolenda, labath, stella.stamenova
Reviewed By: stella.stamenova
Subscribers: lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D68951
llvm-svn: 374803
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: 374584
llvm-svn: 374631
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: 374584
llvm-svn: 374626
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: 374584
llvm-svn: 374622
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: 374584
llvm-svn: 374620
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: 374584
llvm-svn: 374609
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: 374584
Summary:
IOHandler needs to read lines of input from a lldb::File.
The way it currently does this using, FILE*, which is something
we want to avoid now. I'd prefer to just replace the FILE* code
with calls to File::Read, but it contains an awkward and
delicate workaround specific to ctrl-C handling on windows, and
it's not clear if or how that workaround would translate to
lldb::File.
So in this patch, we use use the FILE* if it's available, and only
fall back on File::Read if that's the only option.
I think this is a reasonable approach here for two reasons. First
is that interactive terminal support is the one area where FILE*
can't be avoided. We need them for libedit and curses anyway,
and using them here as well is consistent with that pattern.
The second reason is that the comments express a hope that the
underlying windows bug that's being worked around will be fixed one
day, so hopefully when that happens, that whole path can be deleted.
Reviewers: JDevlieghere, jasonmolenda, labath, lanza
Reviewed By: labath
Subscribers: lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D68622
llvm-svn: 374576
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
Summary:
If you look at what this test is doing, it's actually quite
mysterious why it works at all. It sets the input file
inside a "with open". As soon as the with block ends,
that file will be closed. And yet somehow LLDB reads
commands from it anyway. What's actually happening is that
the file descriptor gets dup'd when something inside LLDB
calls File::GetStream(). I think it's fair to say that
what this test is doing is illegal and it has no right
to expect it to work.
This patch updates the test with two cases. One uses
the SBFile api, and actually transfers ownership of
the original file descriptor to the debugger. The other
just uses the old FILE* API, but in a sane way.
I also set NO_DEBUG_INFO_TESTCASE, because this test doesn't
use any debug info and doesn't need to run three times.
Reviewers: JDevlieghere, jasonmolenda, labath
Reviewed By: labath
Subscribers: aprantl, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D68738
llvm-svn: 374424
Summary:
Python 3.6 stringifies exceptions as `ExceptionClass("foo",)` instead
of `ExceptionClass("foo")`. This patch makes the test assertions a
little more flexible so the test passes anyway.
Reviewers: JDevlieghere, jasonmolenda, labath
Reviewed By: labath
Subscribers: lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D68745
llvm-svn: 374417
Auto-detecting CC in Makefile.rules is no longer useful. Ever since
out-of-tree builds we are better off just running lldb-dotest which
sets it directly. This also makes it harder to accidentally unset CC
in a Makefile.
Differential Revision: https://reviews.llvm.org/D68731
llvm-svn: 374402
When debugging a large program like clang and doing "frame variable
*this", the ValueObject pretty printer is doing hundreds of scoped
FindTypes lookups. The ones that take longest are the ones where the
DWARFDeclContext ends in something like ::Iterator which produces many
false positives that need to be filtered out *after* extracting the
DIEs. This patch demonstrates a way to filter out false positives at
the accerator table lookup step.
With this patch
lldb clang-10 -o "b EmitFunctionStart" -o r -o "f 2" -o "fr v *this" -b -- ...
goes (in user time) from 5.6s -> 4.8s
or (in wall clock) from 6.9s -> 6.0s.
Differential Revision: https://reviews.llvm.org/D68678
llvm-svn: 374401
Before the test reorganization, everything was part of a single test
suite with a single module cache. Now that things are properly separated
this is no longer the case. Only the shell tests inherited the logic to
properly configure and wipe the module caches. This patch adds that
logic back for the API tests. While doing so, I noticed that we were
configuring a Clang module cache in CMake, but weren't actually using it
from dotest.py. I included a fix for that in this patch as well.
Differential revision: https://reviews.llvm.org/D68755
llvm-svn: 374386
Pass the DSYMUTIL and SDKROOT variables on the command line instead of
the environment. This makes it easier to reproduce the make invocation
during development.
Differential revision: https://reviews.llvm.org/D68812
llvm-svn: 374385
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
the exceptions returned differ between swig4 (TypeError) and swig<=3
(NotImplementedError). Just check for the base Exception class instead.
Theoretically we could switch on the swig version and expect the precise
type directly, but checking the exact type does not seem that important.
Thanks to Raphael for helping me figure this out.
llvm-svn: 374322
The test isn't using @expectedFailure correctly, which causes weird
errors, at least with python2, at least with linux. Possibly that
function shouldn't even be public as it's main use is as a backed for
other decorators.
llvm-svn: 374299
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
Jordan Rupprecht