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
Djordje Todorovic