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.
Make it possible to override reproducer capture with the
LLDB_CAPTURE_REPRODUCER environment variable.
The goal of this change is twofold.
(1) I want to be able to enable capturing reproducers during regular
test runs, both locally and on the bots. To do so I need a way to
force capture. I cannot do this through the Python API, because
reproducer capture must be enabled *before* the debugger
initialized, which happens automatically when doing `import lldb`.
(2) I want to provide an escape hatch for when reproducers are enabled
by default. Downstream we have reproducer capture enabled by default
in the driver.
This patch solves both problems by overriding the reproducer mode based
on the environment variable. Acceptable values are 0/1 and ON/OFF.
The changes are minor; primarily debugserver needs to go through
accessor functions/macros when changing pc/fp/sp/lr, and debugserver
needs to clear any existing pointer auth bits from values in two
cases. debugserver can fetch the number of bits used for addressing
from a sysctl, and will include that in the qHostInfo reply. Update
qHostInfo documentation to document it.
The previous fix attempt, in 62a635e864, used too much escaping
for the backslashes.
But instead of using regexes to match both path separator forms,
remove the path altogether to unify the output from the testcase
between platforms.
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
Summary:
The FileSpec class is often used as a sort of a pattern -- one specifies
a bare file name to search, and we check if in matches the full file
name of an existing module (for example).
These comparisons used FileSpec::Equal, which had some support for it
(via the full=false argument), but it was not a good fit for this job.
For one, it did a symmetric comparison, which makes sense for a function
called "equal", but not for typical searches (when searching for
"/foo/bar.so", we don't want to find a module whose name is just
"bar.so"). This resulted in patterns like:
if (FileSpec::Equal(pattern, file, pattern.GetDirectory()))
which would request a "full" match only if the pattern really contained
a directory. This worked, but the intended behavior was very unobvious.
On top of that, a lot of the code wanted to handle the case of an
"empty" pattern, and treat it as matching everything. This resulted in
conditions like:
if (pattern && !FileSpec::Equal(pattern, file, pattern.GetDirectory())
which are nearly impossible to decipher.
This patch introduces a FileSpec::Match function, which does exactly
what most of FileSpec::Equal callers want, an asymmetric match between a
"pattern" FileSpec and a an actual FileSpec. Empty paterns match
everything, filename-only patterns match only the filename component.
I've tried to update all callers of FileSpec::Equal to use a simpler
interface. Those that hardcoded full=true have been changed to use
operator==. Those passing full=pattern.GetDirectory() have been changed
to use FileSpec::Match.
There was also a handful of places which hardcoded full=false. I've
changed these to use FileSpec::Match too. This is a slight change in
semantics, but it does not look like that was ever intended, and it was
more likely a result of a misunderstanding of the "proper" way to use
FileSpec::Equal.
[In an ideal world a "FileSpec" and a "FileSpec pattern" would be two
different types, but given how widespread FileSpec is, it is unlikely
we'll get there in one go. This at least provides a good starting point
by centralizing all matching behavior.]
Reviewers: teemperor, JDevlieghere, jdoerfert
Subscribers: emaste, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D70851
ParseChildMembers does a few things, only one part is actually parsing a single
member. This extracts the member parsing logic into its own function.
This commit just moves the code as-is into its own function and forwards the parameters/
local variables to it, which means it should be NFC.
The only actual changes to the code are replacing 'break's (and one very curious 'continue'
that behaves like a 'break') with 'return's.
Summary: This should allow further simplifications, but it's a first step.
Reviewers: teemperor, jingham, friss
Subscribers: lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D70983
The naming used by editline for the history operations is counter
intuitive to how it's used in lldb for the REPL.
- The H_PREV operation returns the previous element in the history,
which is newer than the current one.
- The H_NEXT operation returns the next element in the history, which
is older than the current one.
This exposed itself as a bug in the REPL where the behavior of up- and
down-arrow was inverted. This wasn't immediately obvious because of how
we save the current "live" entry.
This patch fixes the bug and introduces and enum to wrap the editline
operations that match the semantics of lldb.
Differential revision: https://reviews.llvm.org/D70932
To ensure a reproducer works correctly, the version of LLDB used for
capture and replay must match. Right now the reproducer already contains
the LLDB version. However, this is purely informative. LLDB will happily
replay a reproducer generated with a different version of LLDB, which
can cause subtle differences.
This patch adds a version check which compares the current LLDB version
with the one in the reproducer. If the version doesn't match, LLDB will
refuse to replay. It also adds an escape hatch to make it possible to
still replay the reproducer without having to mess with the recorded
version. This might prove useful when you know two versions of LLDB
match, even though the version string doesn't. This behavior is
triggered by passing a new flag -reproducer-skip-version-check to the
lldb driver.
Differential revision: https://reviews.llvm.org/D70934
Summary:
The IOHandler class source file is currently around 4600 LOC. However only 200
of these lines are concerned with the actual IOHandler class and the rest are the
implementations for Editline, IOHandlerConfirm and the Curses interface. All these
large features also cause that the IOHandler (which is in Core) has a large set of dependencies
on other parts of LLDB.
This patch splits out the code for the curses interface into its own file. This way
the simple IOHandler code is no longer buried in-between much larger functionalities.
Next up is splitting out the other IOHandlers into their own files and then move them
to more appropriate parts of LLDB.
Reviewers: labath, clayborg, JDevlieghere
Reviewed By: labath
Subscribers: mgorny, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D70946
This code was just creating a new SymbolContextList with any found functions
in the front and orders them by how close they are to the current frame.
This refactors this code into its own function to make this more obvious.
Doesn't do any other changes to the code, so this is NFC.
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:
ThreadSafeSTLVector and ThreadSafeSTLMap are not useful for achieving any degree of thread safety in LLDB
and should be removed before they are used in more places. They are only used (unsurprisingly incorrectly) in
`ValueObjectSynthetic::GetChildAtIndex`, so this patch replaces their use there with a simple mutex with which
we guard the related data structures. This doesn't make ValueObjectSynthetic::GetChildAtIndex
any more thread-safe, but on the other hand it at least allows us to get rid of the ThreadSafeSTL* data structures
without changing the observable behaviour of ValueObjectSynthetic (beside that it is now a few bytes smaller).
Reviewers: labath, JDevlieghere, jingham
Reviewed By: labath
Subscribers: lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D70845
This simplifies the CMake logic for adding the Python examples to the
Python package. It unifies the use of create_python_package by adding
the NOINIT option and removes the `target` argument, which is always
`finish_swig`.
If filling in a DataExtractor from an ObjectFile, e.g. via the
ReadSectionData method, the output DataExtractor gets the address
size from the m_data member.
ObjectFile's m_data member is initialized without knowledge about
the address size (so the address size is set based on the host's
sizeof(void*), and at that point within ObjectFile's constructor,
virtual methods implemented in subclasses (like GetAddressByteSize())
can't be called, therefore fix it up when filling in external
DataExtractors.
This makes sure that line tables from executables with a different
address size are parsed properly; previously this tripped up
DWARFDebugLine::LineTable::parse for 32 bit executables on a 64 bit
host, as the address size in the line table (4) didn't match the
one set in the DWARFDataExtractor.
Differential Revision: https://reviews.llvm.org/D70848
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
Extend EmulateMOVRdRm to identify "mov r11, sp" in thumb mode as
setting the frame pointer, if r11 is the frame pointer register.
Differential Revision: https://reviews.llvm.org/D70797
ClangASTSource currently takes a clang::ASTContext and keeps that
around, but a lot of LLDB's functionality for doing operations
on a clang::ASTContext is in its ClangASTContext twin class. We
currently constantly recompute the respective ClangASTContext
from the clang::ASTContext while we instead could just pass and
store a ClangASTContext in the ClangASTSource. This also allows
us to get rid of a bunch of unreachable error checking for cases
where recomputation fails for some reason.
This code is behind a `if (log)` that is always a nullptr as the initializer
was commented out. One could uncomment the initializer code, but then this logging
code just leads to a deadlock as it tries to aquire the module lock.
This removes the logging code until I get this working again.
Summary:
CompileUnit is a complicated class. Having it be implicitly convertible
to a FileSpec makes reasoning about it even harder.
This patch replaces the inheritance by a simple member and an accessor
function. This avoid the need for casting in places where one needed to
force a CompileUnit to be treated as a FileSpec, and does not add much
verbosity elsewhere.
It also fixes a bug where we were wrongly comparing CompileUnit& and a
CompileUnit*, which compiled due to a combination of this inheritance
and the FileSpec*->FileSpec implicit constructor.
Reviewers: teemperor, JDevlieghere, jdoerfert
Subscribers: lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D70827
Summary:
I found the above named method hard to read because it had
a) many nested blocks,
b) one return statement at the end with some logic involved,
c) a duplicated while-loop with just small differences in it.
I decided to refactor this function by employing an early exit strategy.
In order to capture the logic in the return statement and to not have it
repeated more than once I chose to implement a very small lamda function
that captures all the variables it needs.
I also replaced the two while-loops with just one.
This is a non-functional change (NFC).
Reviewers: jdoerfert, teemperor
Reviewed By: teemperor
Subscribers: labath, teemperor, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D70774
This method is only used in ClangASTContext.
Also removes the includes we only needed for the ClangASTContext RTTI check
in the CompilerDecl[Context].cpp files.
Summary:
A most of these tests create FileSpecs with a hardcoded style. Add
utility functions which create a file spec of a given style to simplify
things.
While in there add SCOPED_TRACE messages to tests which loop over
multiple inputs to ensure it's clear which of the inputs failed.
Reviewers: teemperor
Subscribers: lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D70814
Summary:
I found the above named method hard to read because it had
a) many nested blocks and
b) one return statement at the end with some logic involved.
I decided to refactor this function by employing an early exit strategy.
In order to capture the logic in the return statement and to not have it
repeated more than once I chose to implement a very small lamda function
that captures all the variables it needs.
This is a non-functional change (NFC).
Reviewers: jdoerfert
Subscribers: lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D70774
Windows on ARM always uses thumb mode, and doesn't have most of the
mechanisms that are used in e.g. ELF for distinguishing between arm
and thumb.
Differential Revision: https://reviews.llvm.org/D70796
COFF section names can either be stored truncated to 8 chars, in the
section header, or as a longer section name, stored separately in the
string table.
libunwind locates the .eh_frame section by runtime introspection,
which only works for section names stored in the section header (as
the string table isn't mapped at runtime). To support this behaviour,
lld always truncates the section names for sections that will be
mapped, like .eh_frame.
Differential Revision: https://reviews.llvm.org/D70745
Summary:
All these functions are unused from what I can see. Unless I'm missing something here, this code
can go the way of the Dodo.
Reviewers: labath
Reviewed By: labath
Subscribers: abidh, JDevlieghere, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D70770
InitializeContext is useful for allocating a (potentially variable
size) CONTEXT struct in an unaligned byte buffer. In this case, we
already have a fixed size CONTEXT we want to initialize, and we only
used this as a very roundabout way of zero initializing it.
Instead just memset the CONTEXT we have, and set the ContextFlags field
manually.
This matches how it is done in NativeRegisterContextWindows_*.cpp.
This also makes LLDB run successfully in Wine (for a trivial tested
case at least), as Wine hasn't implemented the InitializeContext
function.
Differential Revision: https://reviews.llvm.org/D70742
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.
Summary:
I recently re-discovered that the unsinged stream operators of the
lldb_private::Stream class have a surprising behavior in that they print
the number in hex. This is all the more confusing because the "signed"
versions of those operators behave normally.
Now that, thanks to Raphael, each Stream class has a llvm::raw_ostream
wrapper, I think we should delete most of our formatting capabilities
and just delegate to that. This patch tests the water by just deleting
the operators with the most surprising behavior.
Most of the code using these operators was printing user_id_t values. It
wasn't fully consistent about prefixing them with "0x", but I've tried
to consistenly print it without that prefix, to make it more obviously
different from pointer values.
Reviewers: teemperor, JDevlieghere, jdoerfert
Subscribers: lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D70241
This way it looks more like the code around it. The assert is also gone as it just
checks that the variables we declare directly above were not initialized by anyone.
That made more sense when this was one large function.
Part of the work to split up this monolithic parsing function.
Should be NFC but due to the kafkaesque control flow in this case statement this might
have some unintended side effects.
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:
Adds support for doing range-based for-loops on LLDB's VariableList and
modernises all the index-based for-loops in LLDB where possible.
Reviewers: labath, jdoerfert
Reviewed By: labath
Subscribers: JDevlieghere, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D70668
Summary:
LLDB's ASTDumper is just a clone of Clang's ASTDumper but with some scary code and
some unrelated functionality (like dumping name/attributes of types). This removes LLDB's ASTDumper
and replaces its uses with the `ClangUtils::DumpDecl` method that just calls Clang's ASTDumper
and returns the result as a string.
The few uses where we just want a textual representation of a type (which will print their name/attributes but not
dump any AST) are now also in ClangUtil under a `ToString` name until we find a better home for them.
Reviewers: labath
Reviewed By: labath
Subscribers: mgorny, JDevlieghere, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D70663
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
The in_call_stack Python script makes it possible to modify the last
breakpoint to only stop if a given function is present in the call
stack. It will check both the symbol name and the function name (coming
from the debug info, in case the binary is stripped).
To use this, you have to:
1. Import the script into lldb.
(lldb) command script import in_call_stack.py
2. Set a breakpoint and use the in_call_stack alias.
(lldb) b foo
(lldb) in_call_stack bar
Note that this alias operates on the last set breakpoint. You can re-run
the in_call_stack command to modify the condition.
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
This is a correctness fix for the Clang DWARF parser that primarily
matters for swift-lldb's ability to import Clang types that were
reconstructed from DWARF into Swift.
rdar://problem/55025799
Differential Revision: https://reviews.llvm.org/D70580
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
Improve the message printed when LLDB crashes by asking the user to
replay the reproducer before attaching it to a bugreport..
********************
Crash reproducer for lldb version 10.0.0 (git@github.com:llvm/llvm-project.git revision ...)
clang revision ...
llvm revision ...
Reproducer written to '/path/to/reproducer'
Before attaching the reproducer to a bug report:
- Look at the directory to ensure you're willing to share its content.
- Make sure the reproducer works by replaying the reproducer.
Replay the reproducer with the following command:
./bin/lldb -replay /path/to/reproducer
********************
This patch replaces the existing out-of-date man page for lldb and
replaces it with an RST file from which sphinx generates the actual
troff file. This is similar to how man pages are generated for the rest
of the LLVM utilities.
The man page is generated by building the `docs-lldb-man` target.
Differential revision: https://reviews.llvm.org/D70514
Made small improvements while debugging through
CommandObjectTarget::AddModuleSymbols.
1. Refactored error case for an early out, reducing the indentation of
the rest of this long function.
2. Clarified some comments by correcting spelling and punctuation.
3. Reduced duplicate code at the end of the function.
Tested with `ninja check-lldb`
Differential Review: https://reviews.llvm.org/D70458
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>
This patch hooks the reproducer infrastructure with the signal handlers.
When lldb crashes with reproducers capture enabled, it will now generate
the reproducer and print a short message the standard out. This doesn't
affect the pretty stack traces, which are still printed before.
This patch also introduces a new reproducer sub-command that
intentionally raises a given signal to test the reproducer signal
handling.
Currently the signal handler is doing too much work. Instead of copying
over files into the reproducers in the signal handler, we should
re-invoke ourselves with a special command line flag that looks at the
VFS mapping and performs the copy.
This is a NO-OP when reproducers are disabled.
Differential revision: https://reviews.llvm.org/D70474
Remove hardcoded string prefix length assumption causing issues when
concatenating summary for NSURL in NSURLSummaryProvider. Provider relies
on concatenation of NSStringProvider results for summary, and while the
strings are prefixed with '@' in Objective-C, that is not the case in
Swift causing part of the description to be truncated.
This will be tested in the downstream fork.
Patch by Martin Svensson!
Use TARGET_TRIPLE instead of LLVM_DEFAULT_TARGET_TRIPLE, as the latter
isn't exported by LLVMConfig.cmake, which means arch detection fails if
lldb is built separately from llvm.
Searching persistent decls is a small subset of the things
FindExternalVisibleDecls does. It should be its own function instead
of being encapsulated in this `do { } while(false);` pattern.
This overload is only used in one place and having static overloads for
all methods that only do an additional clang::ASTContext -> ClangASTContext
conversion is just not sustainable.
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
This is an attempt to feature the user-facing resources more
prominently on the LLDB website by calling out the tutorial and the
GDB command map wight on the start page.
I also moved the "Why a new debugger" section to the "Goals"
subpage. Given that LLDB's first release is almost a decade in the
past now, the title is a bit of an anachronism.
Lastly, I moved the Architecture sub-page from "use" to "resources",
since end-users do not care about the source code layout.
Differential Revision: https://reviews.llvm.org/D70449
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.
Summary:
This is some really shady code. It's supposed to kick in after an expression already failed and then try to look
up "unknown types" that for some undocumented reason can't be resolved during/before parsing. Beside the
fact that we never mark any type as `EVUnknownType` in either swift-lldb or lldb (which means this code is unreachable),
this code doesn't even make the expression evaluation succeed if if would ever be executed but instead seems
to try to load more debug info that maybe any following expression evaluations might succeed.
This patch removes ClangExpressionDeclMap::ResolveUnknownTypes and the related data structures/checks/calls.
Reviewers: davide
Reviewed By: davide
Subscribers: aprantl, abidh, JDevlieghere, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D70388
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
We're checking for support but we're discarding the result. My best
guess is that these warnings were disabled in the past. However, I don't
see a reason to keep it that way.
This adds a page about LLDB reproducers. It describes how to use the
reproducers on the command line and lists some of the known
issues/limitations.
Differential revision: https://reviews.llvm.org/D70409
Allow clients of the llvm library to opt-in to one-shot SIGPIPE
handling, instead of forcing them to undo llvm's SIGPIPE handler
registration (which is brittle).
The current behavior is preserved for all llvm-derived tools (except
lldb) by means of a default-`true` flag in the InitLLVM constructor.
This prevents "IO error" crashes in long-lived processes (lldb is the
motivating example) which both a) load llvm as a dynamic library and b)
*really* need to ignore SIGPIPE.
As llvm signal handlers can be installed when calling into libclang
(say, via RemoveFileOnSignal), thereby overriding a previous SIG_IGN for
SIGPIPE, there is no clean way to opt-out of "exit-on-SIGPIPE" in the
current model.
Differential Revision: https://reviews.llvm.org/D70277
Due to alginment and packing using separate members takes up the same
amount of space, but makes it far less cumbersome to deal with it in
constructors etc.
This adds a page named Caveats with a section on some of the things to
be aware of related to Python. It's a question we've seen more than once
pop up and I think it's good to have it documentation on the website.
Even though some of it might be useful to users, I still put it under
"development" because it requires some understanding of how LLDB is
built.
Differential revision: https://reviews.llvm.org/D70252
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
Builtins are rarely if ever accessed via the Preprocessor. They are
typically found on the ASTContext, so there should be no performance
penalty to using a pointer indirection to store the builtin context.
Three uses of try_lock intentionally ignore the result, as explained in
the comment. Make that explicit with a void cast.
Add what appears to be a missing return in the clang expression parser
code. It's a functional change, but presumably the right one.
Differential Revision: https://reviews.llvm.org/D70281
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
For some reason the reproducer tests seem really proficient at
uncovering structural issues in LLDB related to how we tear down things,
but of course only on the bots.
The pretty stack trace helps a bit, but what I really want is the crash
reports which contain much more information, such as what other threads
we doing.
Crash reports are automatically suppressed by lit. This patch
(temporarily) disables that for the reproducer tests.
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 renames the "Goals & Status" section to "Project" and the
"Resources" section to "Development". To better match this layout I've
moved the releases page under "Project".
I wanted to further simplify ParseTypeFromClangModule by replacing the
hand-rolled loop with ForEachExternalModule, and then realized that
ForEachExternalModule also had the problem of visiting the same leaf
node an exponential number of times in the worst-case. This adds a set
of searched_symbol_files set to the function as well as the ability to
early-exit from it.
Differential Revision: https://reviews.llvm.org/D70215
The test was failing due to a bug in SymbolFileDWARF::FindFunctions --
the function was searching the main dwarf unit for DW_TAG_subprograms,
but the main unit is empty in case of split dwarf. The fix is simple --
search the non-skeleton unit instead.
This bug went unnoticed because this function is expensive, and so one
generally avoids calling it.
Summary:
Clang's raw Lexer doesn't produce any tokens for trailing backslashes in a line. This doesn't work with
LLDB's Clang highlighter which builds the source code to display from the list of tokens the Lexer returns.
This causes that lines with trailing backslashes are lacking the backslash and the following newline when
rendering source code in LLDB.
This patch removes the trailing newline from the current line we are highlighting. This way Clang doesn't
drop the backslash token and we just restore the newline after tokenising.
Fixes rdar://57091487
Reviewers: JDevlieghere, labath
Reviewed By: JDevlieghere, labath
Subscribers: labath, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D70177
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
I noticed that currently we are printing LLVM's pretty stack trace
twice. The reason is that we're calling PrintStackTraceOnErrorSignal in
addition to InitLLVM, which besides some other useful things, also
register LLVM's pretty stack trace handler.
Differential revision: https://reviews.llvm.org/D70216
This causes errors when building LLDB because the Windows implementation
doesn't implement this method:
C:\src\llvm-project\lldb\source\Plugins\ScriptInterpreter\Python\ScriptInterpreterPython.cpp(915,19): error: allocating an object of abstract class type 'lldb_private::ConnectionGenericFile'
new ConnectionGenericFile(read_file, true));
^
C:\src\llvm-project\lldb\include\lldb/Utility/Connection.h(174,28): note: unimplemented pure virtual method 'GetReadObject' in 'ConnectionGenericFile'
virtual lldb::IOObjectSP GetReadObject() = 0;
^
This avoids confusing them with fission-related functionality.
I also moved two accessor functions from DWARFDIE into static
functions in DWARFASTParserClang were their only use is located.
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
This fixes the following warning for developers:
Target 'liblldb' was changed to a FRAMEWORK sometime after install(). This
may result in the wrong install DESTINATION. Set the FRAMEWORK property
earlier.
The solution is to pass the FRAMEWORK flag to add_lldb_library and set
the target property before install(). For now liblldb is the only
customer.
Centralize the logic to remove debugserver from
LLVM_DISTRIBUTION_COMPONENTS when LLDB_USE_SYSTEM_DEBUGSERVER is
enabled. Now this happens regardless of whether the tests are enabled.
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
This is basically the same bug as in r260434.
SymbolFileDWARF::FindTypes has exponential worst-case when digging
through dependency DAG of .pcm files because each object file and .pcm
file may depend on an already-visited .pcm file, which may again have
dependencies. Fixed here by carrying a set of already visited
SymbolFiles around.
rdar://problem/56993424
Differential Revision: https://reviews.llvm.org/D70106
This warning triggers when a class defines a copy constructor but not a
copy-assignment operator (which then gets auto-generated by the
compiler). Fix the warning by deleting the other operator too, as the
default implementation works just fine.
Summary:
swift-lldb currently has to patch the ExpressionKind enum to add support for Swift expressions. If we implement LLVM's RTTI
with a static ID variable instead of a centralised enum we can drop that patch.
Reviewers: labath, davide
Reviewed By: labath
Subscribers: JDevlieghere, lldb-commits
Tags: #upstreaming_lldb_s_downstream_patches, #lldb
Differential Revision: https://reviews.llvm.org/D70070
We call IsPossibleDynamicType but we also need to check if this is a Clang type,
otherwise other languages with dynamic types (like Swift) might end up being interpreted
as potential Obj-C dynamic types.
Summary:
I want to be able to specify which python framework to use for lldb in macos. With python2.7 we could just rely on the MacOS one but python3.7 is not shipped with the OS.
An alternative is to use the one shipped with Xcode but that could be path dependent or maybe the user doesn't have Xcode installed at all.
A definite solution is to just ship a python framework with lldb. To make this possible I added "@loader_path/../../../" to the rpath so it points to the same directory as the LLDB.framework, this way we can just drop any frameworks there.
Reviewers: hhb, sgraenitz, xiaobai, smeenai, beanz, labath
Reviewed By: labath
Subscribers: beanz, labath, mgorny, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D69931
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.
Jonas Devlieghere