GDBRemoteCommunicationClient::SendGetSupportedTraceType is checking whether the
response is `!response.IsNormalResponse()` and infers from that that it is an error response.
However, it could be either "unsupported" or "error". If we get an unsupported response,
the code then tries to generate an llvm::Expected from the non-error response which then asserts.
Debugserver doesn't implement `jLLDBTraceSupportedType`, so we get an unsupported response
whenever this function is called on macOS.
This fixes the TestAproposWithProcess on macOS (where the `apropos` command will query
the CommandObjectTraceStart which then sends the trace type query package).
Reviewed By: wallace, shafik
Differential Revision: https://reviews.llvm.org/D91801
We can handle all the types in the expression evaluator now without casting.
On Linux, we have a system header declaration that is still causing issues, so
I'm skipping the test there until I get around to fix this.
Translate between abridged and full ftag values in order to expose
the latter in the gdb-remote protocol while the former are used by
FXSAVE/XSAVE... This matches the gdb behavior.
Differential Revision: https://reviews.llvm.org/D91504
The FXSAVE/XSAVE data can have two different layouts on x86_64. When
called as FXSAVE/XSAVE..., the Instruction Pointer and Address Pointer
registers are reported using a 16-bit segment identifier and a 32-bit
offset. When called as FXSAVE64/XSAVE64..., they are reported using
a complete 64-bit offsets instead.
LLDB has historically followed GDB and unconditionally used to assume
the 32-bit layout, with the slight modification of possibly
using a 32-bit segment register (i.e. extending the register into
the reserved 16 upper bits). When the underlying operating system used
FXSAVE64/XSAVE64..., the pointer was split into two halves,
with the upper half repored as the segment registers. While
reconstructing the full address was possible on the user end (and e.g.
the FPU register tests did that), it certainly was not the most
convenient option.
Introduce a two additional 'fip' and 'fdp' registers that overlap
with 'fiseg'/'fioff' and 'foseg'/'foff' respectively, and report
the complete 64-bit address.
Differential Revision: https://reviews.llvm.org/D91497
Depends on D90490.
The stop command is simple and invokes the new method Trace::StopTracingThread(thread).
On the other hand, the start command works by delegating its implementation to a CommandObject provided by the Trace plugin. This is necessary because each trace plugin needs different options for this command. There's even the chance that a Trace plugin can't support live tracing, but instead supports offline decoding and analysis, which means that "thread trace dump instructions" works but "thread trace start" doest. Because of this and a few other reasons, it's better to have each plugin provide this implementation.
Besides, I'm using the GetSupportedTraceType method introduced in D90490 to quickly infer what's the trace plug-in that works for the current process.
As an implementation note, I moved CommandObjectIterateOverThreads to its header so that I can use it from the IntelPT plugin. Besides, the actual start and stop logic for intel-pt is not part of this diff.
Reviewed By: clayborg
Differential Revision: https://reviews.llvm.org/D90729
I noticed that Process is inheriting from UserID to store its PID value. This patch
replaces this with a dedicated field in the Process class. This is NFC, but has some
small effects on the code using Process:
* `GetID()` now returns a `lldb::pid_t` like all other process code instead of `lldb::user_id_t`. Both are typedefs for `uint64_t`, so no change in behaviour.
* The equality operators defined for UserID no longer accept Process instances.
* Removes the inherited method `Process::Clear()` which didn't actually clear anything beside the PID value.
We maybe should also remove the getters/setters to `S/GetPID` or something like that. I can update all the code for that
in a follow-up NFC commit.
Reviewed By: labath
Differential Revision: https://reviews.llvm.org/D91699
init_llgs_test no longer takes an argument
but these two were not updated.
Also fix some mistakes in TestAutoInstallMainExecutable
to get it passing again.
Reviewed By: JDevlieghere, labath
Differential Revision: https://reviews.llvm.org/D91612
Adds a command line option that makes debugserver propagate the SIGSEGV
signal to the target process.
Motivation: I'm one of the maintainers of Delve [1] a debugger for Go.
We use debugserver as our backend on macOS and one of the most often
reported bugs is that, on macOS, we don't propagate SIGSEGV back to the
target process [2]. Sometimes some programs will actually cause a
SIGSEGV, by design, and then handle it. Those programs can not be
debugged at all.
Since catching signals isn't very important for a Go debugger I'd much
rather have a command line option in debugserver that causes it to let
SIGSEGV go directly to the target process.
[1] https://github.com/go-delve/delve/
[2] https://github.com/go-delve/delve/issues/852
Differential revision: https://reviews.llvm.org/D89315
This moves in the direction of our effort to synchronize register descriptions
between LLDB and GDB xml description. We want to able to send registers in a
way that their offset fields can be re-constructed based on register sizes
in the increasing order of register number.
In context to Arm64 SVE, FPCR and FPSR are same registers in FPU regset and
SVE regset. Previously FPSR/FPCR offset was set at the end of SVE data
because Linux ptrace data placed FPCR and FPSR at the end of SVE register set.
Considering interoperability with other stubs like QEMU and that g packets
should generate register data in increasing order of register numbers. We
have to move FPCR/FPSR offset up to its original location according to
register numbering scheme of ARM64 registers with SVE registers included.
Reviewed By: labath
Differential Revision: https://reviews.llvm.org/D90741
In our recent discussion we are aiming to make LLDB registers exchange minimum
possible information in qRegisterInfo or XMl register descriptions.
For SVE registers, Z registers are catagorized as primary registers and should
not have any infomration about any pseudo registers. All pseudo registers
should have the information on which primary register they belong to.
This patch removes invalidate_regs list from Z registers and will mitigate its
impact on SVE resize patch in a follow up update.
Reviewed By: labath
Differential Revision: https://reviews.llvm.org/D91057
Add a parser for JSON crashlogs. The CrashLogParser now defers to either
the JSONCrashLogParser or the TextCrashLogParser. It first tries to
interpret the input as JSON, and if that fails falling back to the
textual parser.
Differential revision: https://reviews.llvm.org/D91130
LLDB is currently always activating C++ when parsing expressions as LLDB itself
is using C++ features when creating the final AST that will be codegen'd
(specifically, references to variables, namespaces and using declarations are
used).
This is causing problems for users that have variables in non-C++ programs (e.g.
plain C or Objective-C) that have names which are keywords in C++. Expressions
referencing those variables fail to parse as LLDB's Clang parser thinks those
identifiers are C++ keywords and not identifiers that may belong to a
declaration.
We can't just disable C++ in the expression parser for those situations as
replacing the functionality of the injected C++ code isn't trivial. So this
patch is just disabling most keywords that are exclusive to C++ in LLDB's Clang
parser when we are in a non-C++ expression. There are a few keywords we can't
disable for now:
* `using` as that's currently used in some situations to inject variables into the expression function.
* `__null` as that's used by LLDB to define `NULL`/`Nil`/`nil`.
Getting rid of these last two keywords is possible but is a large enough change
that this will be handled in follow up patches.
Note that this only changes the keyword status of those tokens but this patch
does not remove any C++ functionality from the expression parser. The type
system still follows C++ rules and so does the rest of the expression parser.
There is another small change that gives the hardcoded macro definitions in LLDB
a higher precedence than the macros imported from the Objective-C modules. The
reason for this is that the Objective-C modules in LLDB are actually parsed in
Objective-C++ mode and they end up providing the C++ definitions of certain
system macros (like `NULL` being defined as `nullptr`). So we have to move the
LLDB definition forward and surround the definition from the module with an
`#ifdef` to make sure that we use the correct LLDB definition that doesn't
reference C++ keywords. Or to give an example, this is how the expression source
code changes:
Before:
```
#define NULL (nullptr) // injected module definition
#ifndef NULL
#define NULL (__null) // hardcoded LLDB definition
#endif
```
After:
```
#ifndef NULL
#define NULL (__null) // hardcoded LLDB definition
#endif
#ifndef NULL
#define NULL (nullptr) // injected module definition
#endif
```
Fixes rdar://10356912
Reviewed By: shafik
Differential Revision: https://reviews.llvm.org/D82770
Create a helper GetOffsetRegSetData() method to get pointer
to the regset data accounting for the necessary offset. Establish
the offsets in the constructor and store them in the structure. This
avoids having to add new Get*Offset() methods and combines some common
code.
Differential Revision: https://reviews.llvm.org/D91411
Eliminate the remaining swith-case code for register getters,
and migrate YMM registers to regset-oriented model. Since these
registers are recombined from XMM and YMM_Hi128 XSAVE blocks, while LLDB
gdb-server protocol transmits YMM registers whole, the offset-based
model will not work here. Nevertheless, some improvement was possible.
Replace generic 'XSaveRegSet' along with sub-sets for XSAVE components
with 'YMMRegSet' (and more regsets in the future as further components
are implemented). Create a helper GetYMMSplitReg() method that obtains
pointers to the appropriate XMM and YMM_Hi128 blocks to reduce code
duplication.
Differential Revision: https://reviews.llvm.org/D91293
Use offset-based method to access x86 debug registers. This also
involves adding a test for the correctness of these offsets, and making
GetDR() method of NativeRegisterContextWatchpoint_x86 public to avoid
duplicate code.
Differential Revision: https://reviews.llvm.org/D91268
Use offset-based method to access base x87 FPU registers, using offsets
relative to the position of 'struct FPR', as determined by the location
of first register in it (fctrl). Change m_fpr to use a fixed-size array
matching FXSAVE size (512 bytes). Add unit tests for verifying
RegisterInfo offsets and sizes against the FXSAVE layout.
Differential Revision: https://reviews.llvm.org/D91248
Read and write registers from m_gpr using offsets from RegisterInfo
rather than explicit switch-case. This eliminates a lot of redundant
code, and avoids mistakes such as type mismatches seen recently (wrt
segment registers). The same logic will be extended to other register
sets in the future.
Make m_gpr an uint8_t std::array to ease accesses. Ideally, we could
avoid including <machine/reg.h> entirely in the future and instead
get the correct GPR size from Utility/RegisterContextFreeBSD_* somehow.
While at it, modify register set logic to use an explicit enum with
llvm::Optional<>, making the code cleaner and at the same time enabling
compiler warnings for unhandled sets.
Since now we're fully relying on 'struct GPR' defined
in Utility/RegisterContextFreeBSD_* being entirely in sync with
the system structure, add unit tests to verify the field offsets
and sizes.
Differential Revision: https://reviews.llvm.org/D91216
I think the check for whether the process is connected is totally bogus
in the first place, but on the off-chance that's it's not, we should
behave the same in synchronous and asynchronous mode.
I only have a crash report for this. I could reproduce it with a slightly older
lldb by running an expression that called pthread_kill, but we started making modules
for our expression JIT code, so that no longer triggers the bug. I can't think of another
good way to test it but the fix is obvious.
"[lldb/DataFormatters] Display null C++ pointers as nullptr" added an assumption
that the member we check for is always a nullptr, but it is actually never
initialized. That causes the test to randomly fail due to the pointer having
some random value that isn't 0.
On x86_64, when you hit a __builtin_debugtrap instruction, you
can continue past this in the debugger. This patch has debugserver
recognize the specific instruction used for __builtin_debugtrap
and advance the pc past it, so that the user can continue execution
once they've hit one of these.
In the patch discussion, we were in agreement that it would be better
to have this knowledge up in lldb instead of depending on each
stub rewriting the pc behind the debugger's back, but that's a
larger scale change for another day.
<rdar://problem/65521634>
Differential revision: https://reviews.llvm.org/D91238
Display null pointer as `nullptr`, `nil` and `NULL` for C++,
Objective-C/Objective-C++ and C respectively. The original motivation
for this patch was to display a null std::string pointer as nullptr
instead of "", but the fix seemed generic enough to be done for all
summary providers.
Differential revision: https://reviews.llvm.org/D77153
When parsing DWARF and laying out bit-fields we don't properly take into account when they are in a union, they will all have a zero offset.
Differential Revision: https://reviews.llvm.org/D91118
When I added TestAbortExitCode I actually planned this to be a generic test for the
exit code functionality on POSIX systems. However due to all the different test setups we
can have I don't think this worked out. Right now the test had to be made so permissive
that it pretty much can't fail.
Just to summarize, we would need to support the following situations:
1. ToT debugserver (on macOS)
2. lldb-server (on other platforms)
3. Any old debugserver version when using the system debugserver (on macOS)
This patch is removing TestAbortExitCode and adds a ToT debugserver specific test
that checks the patch that motivated the whole exit code testing. There is already
an exit-code test for lldb-server from what I can see and 3) is pretty much untestable
as we don't know anything about the system debugserver.
Reviewed By: kastiglione
Differential Revision: https://reviews.llvm.org/D89305
This adds `expect_var_path` to test variable paths so we no longer have to
use `frame var` and find substrs in the command output. The behaviour
is identical with `expect_expr` (and it also uses the same checking backend),
but it instead calls `GetValueForVariablePath` to evaluate the string as a variable
path.
Also rewrites a few of the tests that previously used `frame variable` to use
`expect_var_path`.
Reviewed By: labath
Differential Revision: https://reviews.llvm.org/D90450
Add a test verifying that after the 'watchpoint' command, new values
of x86 debug registers can be read back correctly. The primary purpose
of this test is to catch broken DRn reading and help debugging it.
Differential Revision: https://reviews.llvm.org/D91264
Fix Debug Register offsets to be specified relatively to UserArea
on FreeBSD/amd64 and FreeBSD/i386, and add them to UserArea on i386.
This fixes overlapping GPRs and DRs in gdb-remote protocol, making it
impossible to correctly get and set debug registers from the LLDB
client.
Differential Revision: https://reviews.llvm.org/D91254
This reverts commit 856fd98a17. The type formatters
use inline namespaces to find the formatter that fits the type ABI, so they
can't just ignore the inline namespaces.
The failing tests should be fixed by da121fff11 .
Commit 5f12f4ff90 made suppressing inline namespaces
when printing typenames default to true. As we're using the inline namespaces
in LLDB to construct internal type names (which need internal namespaces in them
to, for example, differentiate libc++'s std::__1::string from the std::string
from libstdc++), this broke most of the type formatting logic.
Following discussion in D91193, a change made in D88792 was not quite right.
This restores the message argument, and switches from `expect` to `runCmd`.
Differential Revision: https://reviews.llvm.org/D91206
Buildbot failed on Windows
http://lab.llvm.org:8011/#/builders/83/builds/693
Error: On Windows, std::future can't hold an Expected, as it doesn't have a default
constructor.
Solution: Use std::future<bool> instead of std::future<Expected<T>>
Depends on D89283.
The goal of this packet (jTraceGetSupportedType) is to be able to query the gdb-server for the tracing technology that can work for the current debuggeer, which can make the user experience simpler but allowing the user to simply type
thread trace start
to start tracing the current thread without even telling the debugger to use "intel-pt", for example. Similarly, `thread trace start [args...]` would accept args beloging to the working trace type.
Also, if the user typed
help thread trace start
We could directly show the help information of the trace type that is supported for the target, or mention instead that no tracing is supported, if that's the case.
I added some simple tests, besides, when I ran this on my machine with intel-pt support, I got
$ process plugin packet send "jTraceSupportedType"
packet: jTraceSupportedType
response: {"description":"Intel Processor Trace","pluginName":"intel-pt"}
On a machine without intel-pt support, I got
$ process plugin packet send "jTraceSupportedType"
packet: jTraceSupportedType
response: E00;
Reviewed By: clayborg, labath
Differential Revision: https://reviews.llvm.org/D90490
Those two decorators have identical behaviour. This removes
`not_remote_testsuite_ready` as `skipIfRemote` seems more consistent with the
other decorator names we have
Reviewed By: JDevlieghere
Differential Revision: https://reviews.llvm.org/D89376
Copy the recent improvements from the FreeBSDRemote plugin, notably:
- moving event reporting setup into SetupTrace() helper
- adding more debug info into SIGTRAP handling
- handling user-generated (and unknown) SIGTRAP events
- adding missing error handling to the generic signal handler
- fixing attaching to processes
- switching watchpoint helpers to use llvm::Error
- minor style and formatting changes
This fixes a number of tests, mostly related to fixed attaching.
Differential Revision: https://reviews.llvm.org/D91167
Instead of having a custom error message, propagate the llvm::Error from
SystemInitializerCommon. I didn't realize we had this overload until
Pavel mentioned it in D90987 today.
Dwarf says (Section 2.5.1.1. of DWARF v5) that these operations should
push "generic" (pointer-sized) values. This was not the case for
DW_OP_const operations (which were pushing values based on the size of
arguments), nor DW_OP_litN (which were always pushing 64-bit values).
The practical effect of this that were were unable to display the values
of variables if the size of the DW_OP_const opcode was smaller than the
value of the variable it was describing. This would happen because we
would store this (small) result into a buffer and then would not be able
to read sufficient data out of it (in Value::GetValueAsData). Gcc emits
debug info like this.
Other (more subtle) effects are also possible.
The same fix should be applied to DW_OP_const[us] (leb128 versions), but
I'm not doing that right now, because that would cause us to display
wrong (truncated) values of variables on 32-bit targets (pr48087).
Differential Revision: https://reviews.llvm.org/D90840
It seems that TestErrorMessages.test is failing on the standalone + Xcode builds
as lldb-server executable can't be found by lit's default PATH search. I assume
invoking lldb-server via a lit substitution gets this working again as
everything else is working, so that's what this patch is doing.
I had to add the lldb-server substitution as the test seems lldb-server specific
and we don't want it to default to debugserver on Darwin.
Using a substitution also seems in general like a good idea so that the commands
lit is printing on failure are using the full path to lldb-server and can be
re-run in a terminal.
Reviewed By: labath
Differential Revision: https://reviews.llvm.org/D91155
Explicitly copy dbregs to new threads to ensure that watchpoints
are propagated properly. Fixes the test failure due to apparent kernel
race between reporting a new thread and resuming main thread execution
that makes implicit inheritance of dbregs unreliable. By copying them
explicitly, we ensure that the new thread correctly respects watchpoints
that were set after the thread was created but before it was reported.
The code is copied from the NetBSD plugin and modernized to use
llvm::Error.
Differential Revision: https://reviews.llvm.org/D91032
Fix DS/ES/FS/GS register sizes in getter/setter for FreeBSD. Apparently
only CS and SS registers are specified as 64/32-bit in LLDB, while
the others are specified as 16-bit. This fixes the failing
StandardStartupTest.TestStopReplyContainsThreadPcs lldb-server unittest.
Differential Revision: https://reviews.llvm.org/D91076
Update the SIGTRAP handler to account for the possibility of SIGTRAP
being generated by the user, i.e. not having any specific debugging
event associated with it, as well as receiving unknown SIGTRAPs. These
instances of SIGTRAP are passed to the regular signal handler.
Differential Revision: https://reviews.llvm.org/D91007
Make category-specifying files visible. There is really no good reason
to keep them hidden, and having them visible increases the chances
that someone will actually spot them.
Differential Revision: https://reviews.llvm.org/D91065
Replace the plethora of ObjC-implied 'skipUnlessDarwin' decorators
with marking tests as 'objc' category (whenever missing), and skip all
ObjC tests on non-Darwin platforms. I have used '.categories' file
wherever it was present already or all (>1) tests were relying on ObjC,
and explicit add_test_categories() where there was only one test.
Differential Revision: https://reviews.llvm.org/D91056
Part 2 of a fix for JITed code debugging. This has been a regression from 5.0 to 6.0 and it's still reproducible on current master: https://bugs.llvm.org/show_bug.cgi?id=36209 Part 1 was D61611 a while ago.
The in-memory object files we obtain from JITLoaderGDB are not yet relocated. It looks like this used to happen on the LLDB side and my guess is that it broke with D38142. (However, it's hard to tell because the whole thing was broken already due to the bug in part 1.) The patch moved relocation resolution to a later point in time and didn't apply it to in-memory objects. I am not aware of any reason why we wouldn't resolve relocations per-se, so I made it unconditional here. On Debian, it fixes the bug for me and all tests in `check-lldb` are still fine.
Reviewed By: labath
Differential Revision: https://reviews.llvm.org/D90769
This fixes a reproducer test failure that was caused by the undefined
order in which global destructors run. More concretely, the static
instance of the RealFileSystem had been destroyed before we finalized
the reproducer, which uses it to copy files into the reproducer. By
exiting normally, we call SBDebugger::Terminate and finalize the
reproducer before any static dtors are run.
Fix DS/ES/FS/GS register sizes in getter/setter for NetBSD. Apparently
only CS and SS registers are specified as 64/32-bit in LLDB, while
the others are specified as 16-bit.
Differential Revision: https://reviews.llvm.org/D91090
During active replay, the ::Initialize call is replayed like any other
SB API call and the return value is ignored. Since we can't intercept
this, we terminate here before the uninitialized debugger inevitably
crashes.
Differential revision: https://reviews.llvm.org/D90987
I found a few cases where entries in the debug_line for a specific line of code have invalid entries (the address is outside of a code section or no section at all) and also valid entries. When this happens lldb might not set the breakpoint because the first line entry it will find in the line table might be the invalid one and since it's range is "invalid" no location is resolved. To get around this I changed the way we parse the line sequences to ignore those starting at an address under the first code segment.
Greg suggested to implement it this way so we don't need to check all sections for every line sequence.
Reviewed By: clayborg
Differential Revision: https://reviews.llvm.org/D87172
When LLDB Python bindings are used and stack backtraces are enabled
for logging, getMainExecutable() is called with argv0 being null.
This caused the fallback function getprogpath() (used on FreeBSD, NetBSD
and Linux) to segfault. Make it handle null executable name gracefully.
Differential Revision: https://reviews.llvm.org/D91012
TestWatchpointMultipleThreads currently accounts for two scenarios:
setting the watchpoint before a new thread starts (presumably, verifying
that it will be propagated to the new thread) and setting it after
the thread starts (presumably, verifying that a new watchpoint is set
on all threads). However, the latter test currently assumes that
the thread will be reported to the debugger before the breakpoint is
hit. This is not the case on FreeBSD and NetBSD.
On NetBSD, new threads do not inherit debug registers from their parent
threads. Instead, LLDB copies them manually after the new thread is
reported. Since the thread is actually reported after the second
breakpoint location, both tests effectively check the same behavior
(i.e. watchpoint being set before the new thread is reported).
On FreeBSD, new threads inherit debug registers and we seem to hit
an interesting race condition. While the thread is reported after
the breakpoint is hit, the kernel seems to construct it and copy
the debug register before that happens. As a result, setting
the watchpoint at the second breakpoint location modifies the debug
registers of the first thread after they have been copied to the second
thread but before the debugger is aware of it. Therefore,
the watchpoint is not propagated to the second thread and the test
fails.
Extend the test to cover all three possible scenarios: setting
watchpoint before the thread is lanched, after it is launched but before
it is guaranteed to have started and after it has actually started. Add
a second barrier to account for the last case. This should ensure that
the second assumption (i.e. that the watchpoint is set on all currently
known threads) is actually tested on FreeBSD and NetBSD.
Differential Revision: https://reviews.llvm.org/D91030
This would be reproducible in future DWZ category of the testsuite as:
Failed Tests (1):
lldb-api :: python_api/symbol-context/two-files/TestSymbolContextTwoFiles.py
Differential Revision: https://reviews.llvm.org/D91014
Use skipUnlessDarwin decorator for tests that are specific to Darwin,
instead of skipIf... for all other platforms. This should make it clear
that these tests are not supposed to work elsewhere. It will also make
these tests stop repeatedly popping up while I look for tests that could
be fixed on the platform in question.
Differential Revision: https://reviews.llvm.org/D91003
Sometimes builds will fail with errors like:
```
In file included from /build/external/llvm-project/lldb/source/Symbol/SwiftASTContext.cpp:52:
In file included from /build/external/swift/include/swift/IRGen/Linking.h:22:
In file included from /build/external/swift/include/swift/SIL/SILFunction.h:24:
In file included from /build/external/swift/include/swift/SIL/SILBasicBlock.h:23:
In file included from /build/external/swift/include/swift/SIL/SILInstruction.h:21:
In file included from /build/external/swift/include/swift/AST/Builtins.h:24:
**/build/external/llvm-project/llvm/include/llvm/IR/Attributes.h:74:14: fatal error: 'llvm/IR/Attributes.inc' file not found**
**^~~~~~~~~~~~~~~~~~~~~~~~**
```
This change ensures the `Attributes.inc` file is generated before building `SwiftASTContext.cpp`.
Differential Revision: https://reviews.llvm.org/D90857
Use positive logic (i.e. llgs_platform/debugserver_platform) for
indicating which platforms use the particular server variant.
Deduplicate the lists — it is rather expected that none of the platforms
using LLGS would use debugserver.
Differential Revision: https://reviews.llvm.org/D90875
Depends on D89408.
This diff finally implements trace decoding!
The current interface is
$ trace load /path/to/trace/session/file.json
$ thread trace dump instructions
thread #1: tid = 3842849, total instructions = 22
[ 0] 0x40052d
[ 1] 0x40052d
...
[19] 0x400521
$ # simply enter, which is a repeat command
[20] 0x40052d
[21] 0x400529
...
This doesn't do any disassembly, which will be done in the next diff.
Changes:
- Added an IntelPTDecoder class, that is a wrapper for libipt, which is the actual library that performs the decoding.
- Added TraceThreadDecoder class that decodes traces and memoizes the result to avoid repeating the decoding step.
- Added a DecodedThread class, which represents the output from decoding and that for the time being only stores the list of reconstructed instructions. Later it'll contain the function call hierarchy, which will enable reconstructing backtraces.
- Added basic APIs for accessing the trace in Trace.h:
- GetInstructionCount, which counts the number of instructions traced for a given thread
- IsTraceFailed, which returns an Error if decoding a thread failed
- ForEachInstruction, which iterates on the instructions traced for a given thread, concealing the internal storage of threads, as plug-ins can decide to generate the instructions on the fly or to store them all in a vector, like I do.
- DumpTraceInstructions was updated to print the instructions or show an error message if decoding was impossible.
- Tests included
Differential Revision: https://reviews.llvm.org/D89283
This test requires running under the Python we built against (which is
easy) and setting up the PYTHONPATH (which is not worth it for this
simple test).
AFAICT, ~TargetList simply implements the default destructor, plus some
locking.
The history is murky, so I'm not sure why we do this locking. Perhaps,
at some point, it was possible to delete the same TargetList instance
from two different threads, setting up a race. If that were true, then
the locking would protect against the race.
Since TargetList is uniquely owned by Debugger (m_target_list), no such
race is possible today.
Testing: check-lldb
Differential Revision: https://reviews.llvm.org/D90895
Factor out dummy target creation from CreateTargetInternal.
This makes it impossible for dummy target creation to accidentally fail
due to too-strict checking in one of the CreateTargetInternal overloads.
Testing: check-lldb
rdar://70630655
Differential Revision: https://reviews.llvm.org/D90872
This patch changes the implementation of Lua's `print()` function to
respect `io.stdout`.
The original implementation uses `lua_writestring()` internally, which is
hardcoded to `stdout`.
Reviewed By: JDevlieghere
Differential Revision: https://reviews.llvm.org/D90787
Remove the thread name caching code. It does not handle the possibility
of thread name changing between requests, therefore breaking
TestGdbRemoteThreadName. While technically we could cache the results
and reset the cache on resuming process, the gain from doing that
does not seem worth the effort.
Differential Revision: https://reviews.llvm.org/D90863
Fix TestGdbRemoteThreadName to call ::pthread_setname_np instead
of ::pthread_set_name_np on FreeBSD. While technically both names
are correct, the former is preferable because of compatibility
with Linux. Furthermore, the latter requires `#include <pthread_np.h>`
that was missing causing the test to fail to compile.
Differential Revision: https://reviews.llvm.org/D90862
The new FreeBSDRemote plugin has reached feature parity on i386
and amd64 targets. Use it by default on these architectures, while
allowing the use of the legacy plugin via FREEBSD_LEGACY_PLUGIN envvar.
Revisit the method of switching plugins. Apparently, the return value
of PlatformFreeBSD::CanDebugProcess() is what really decides whether
the legacy or the new plugin is used.
Update the test status. Reenable the tests that were previously
disabled on FreeBSD and do not cause hangs or are irrelevant to FreeBSD.
Mark all tests that fail reliably as expectedFailure. For now, tests
that are flaky (i.e. produce unstable results) are left enabled
and cause unpredictable test failures.
Differential Revision: https://reviews.llvm.org/D90757
5d64574301 removes this enum value and now
all the switch statements that previously relied on handling this in the
'default' branch are causes compiler warnings due to redundant default cases.
This just removes the now unreachable code in there.
In D89056 the default value for architecture was moved to `build` so that
all called functions see the same architecture value. It seems there are a
few functions that call buildDefault directly (and not via build), so
on some test configurations that set a custom arch value the architecture
value is no longer available.
This just adds the architecture code from build to buildDefault to get
the bots green again while I'm looking for a better solution.
This just adds the simulator platforms to the lldbplatform enumerations
and the respective test decorator.
The platform names for the simulator are just the SDK names since D85537, so
that's why we are not using LLDB's usual platform names here (e.g., SDK =
"iphonesimulator" vs LLDB platform ="ios-simulator").
Also removes the duplicate platform enumaration in lldbplatformutil.py.
Reviewed By: JDevlieghere
Differential Revision: https://reviews.llvm.org/D89694
This originally broke the TestQuoting which explicitly called buildDefault
instead of calling build() and marking the test as no_debug_info_test.
TestQuoting has been rewritten by now and is using `build`, so this should now
pass on all platforms.
Original summary:
The Darwin builder currently assumes in `getArchCFlags` that the passed `arch`
value is an actual string it can string.join with vendor/os/version/env strings:
```
triple = '-'.join([arch, vendor, os, version, env])
```
However this is not true for most tests as we just pass down the `arch=None`
default value from `TestBase.build`. This causes that if we actually end up in
this function we just error out when concatenating `None` with the other actual
strings of vendor/os/version/env. What we should do instead is check that if
there is no test-specific architecture that we fall back to the configuration's
architecture value.
It seems we already worked around this in `builder.getArchSpec` by explicitly
falling back to the architecture specified in the configuration.
This patch just moves this fallback logic to the top `build` function so that it
affects all functions called from `TestBase.build`.
Reviewed By: JDevlieghere
Differential Revision: https://reviews.llvm.org/D89056
`fork` is marked as `__WATCHOS_PROHIBITED __TVOS_PROHIBITED` so the test source
which is calling fork will never compile on watchOS/tvOS. This just adds the
skip decorator for these platforms.
Reviewed By: mib
Differential Revision: https://reviews.llvm.org/D89695
This is a follow up to D88792 which found an issue in a call to PExpectTest's
expect function that allows passing a string to the `substrs` parameter. However
this issue was found by just grepping and TestPExpect's expect function is still
accepting a single string as a value to `substrs`.
This patch adds the same sanity check that D88792 added to the PExpectTest's
implementation of `expect` and also adds a small test for it.
Reviewed By: kastiglione, JDevlieghere
Differential Revision: https://reviews.llvm.org/D89302
The lldb.debugger et al convenience variables are only available from
the interactive script interpreter. In all other scenarios, they are
None (since fc1fd6bf9f) before that they
were default initialized.
The crashlog script was hacking around that by setting the lldb.debugger
to a newly created debugger instance when running outside of the script
interpreter, which works fine until lldb creates a script interpreter
instance under the hood and clears the variables. This was resulting in
an AttributeError when invoking the script directly (from outside of
lldb):
AttributeError: 'NoneType' object has no attribute 'GetSourceManager'
This patch fixes that by passing around the debugger instance.
rdar://64775776
Differential revision: https://reviews.llvm.org/D90706
This class and it's surroundings contain a lot of shady code, but as far
as I can tell all of that code is unreachable (there is no code actually
setting the value to eValueTypeVector).
According to history this class was introduced in 2012 in
r167033/0665a0f09. At that time, the code seemed to serve some purpose,
and it had two entry points (in Value::SetContext and
ClangExpressionDeclMap::LookupDecl). The first entry point was deleted
in D17897 and the second one in r179842/44342735.
The stated purpose of the patch introducing this class was to fix
TestRegisters.py, and "expr $xmm0" in particular. Both of these things
function perfectly well these days without this class.
SBType::GetArrayElementType should return the actual type, not the
canonical type (e.g. int32_t, not the underlying int).
Added a test case to validate the new behavior. I also ran all other
tests on Linux (ninja check-lldb), they all pass.
Differential revision: https://reviews.llvm.org/D90318
Instead of parsing the crashlog in one big loop, use methods that
correspond to the different parsing modes.
Differential revision: https://reviews.llvm.org/D90665
This patch is a minor suggestion to not rely on the fact
that the `LUA_OK` macro is 0.
This assumption could change in future versions of the C API.
Differential Revision: https://reviews.llvm.org/D90556
Disable GetMemoryRegionInfo() in order to unbreak expression parsing.
For some reason, the presence of non-stub function causes LLDB to fail
to detect system libraries correctly. Through being unable to find
mmap() and allocate memory, this leads to expression parser being
broken.
The issue is non-trivial and it is going to require more time debugging.
On the other hand, the downsides of missing the function are minimal
(2 failing tests), and the benefit of working expression parser
justifies disabling it temporarily. Furthermore, the old FreeBSD plugin
did not implement it anyway, so it allows us to switch to the new plugin
without major regressions.
The really curious part is that the respective code in the NetBSD plugin
yields very similar results, yet does not seem to break the expression
parser.
Differential Revision: https://reviews.llvm.org/D90650
Remove the NetBSD-specific override of GetSharedLibraryInfoAddress(),
restoring the generic implementation from NativeProcessELF.
Differential Revision: https://reviews.llvm.org/D90620
Fix two bugs that caused attaching to a process in a pre-connected
lldb-server to fail. These are:
1. Prematurely reporting status in NativeProcessFreeBSD::Attach().
The SetState() call defaulted to notify the process, and LLGS tried
to send the stopped packet before the process instance was assigned
to it. While at it, add an assert for that in LLGS.
2. Duplicate call to ReinitializeThreads() (via SetupTrace()) that
overwrote the stopped status in threads. Now SetupTrace() is called
directly by NativeProcessFreeBSD::Attach() (not the Factory) in place
of ReinitializeThreads().
This fixes at least commands/process/attach/TestProcessAttach.py
and python_api/hello_world/TestHelloWorld.py.
Differential Revision: https://reviews.llvm.org/D90525
Fix process matching by name to make 'process attach -n ...' work.
The process finding code has an optimization that defers getting
the process name and executable format after the numeric (PID, UID...)
parameters are tested. However, the ProcessInstanceInfoMatch.Matches()
method has been matching process name against the incomplete process
information as well, and effectively no process ever matched.
In order to fix this, create a copy of ProcessInstanceInfoMatch, set
it to ignore process name and se this copy for the initial match.
The same fix applies to FreeBSD and NetBSD host code.
Differential Revision: https://reviews.llvm.org/D90454
Implement NativeThreadFreeBSD::GetName(). This is based
on the equivalent code in the legacy FreeBSD plugin, except it is
modernized a bit to use llvm::Optional and std::vector for data storage.
Differential Revision: https://reviews.llvm.org/D90298
Python doesn't support enums before PEP 435, but using a class with
constants is how it's commonly emulated. It can be converted into a real
Enum (in Python 3.4 and later) by extending the Enum class:
class CrashLogParseMode(Enum):
NORMAL = 0
THREAD = 1
IMAGES = 2
THREGS = 3
SYSTEM = 4
INSTRS = 5
This patch calls `lua_close()` on Lua dtor.
This guarantees that the Lua GC finalizers are honored, aside from the
usual internal clean up.
It also guarantees a call to the `__close` metamethod of any active
to-be-closed variable in Lua 5.4.
Since the previous `luaL_openlibs()` was a noop, because the standard
library is cached internally, I've removed it.
Differential Revision: https://reviews.llvm.org/D90557
Changed two references to developers as "he" or "him" to the more neutral "they".
Reviewed By: JDevlieghere, sylvestre.ledru
Differential Revision: https://reviews.llvm.org/D78807
This allows the Target to update its module list when loading a shared
module replaces an equivalent one.
A testcase is added which hits this codepath -- without the fix, the
target reports libbreakpad.so twice in its module list.
Reviewed By: jingham
Differential Revision: https://reviews.llvm.org/D89157
The various GetSharedModule methods have an optional out parameter for
the old module when a file has changed or been replaced, which the
Target uses to keep its module list current/correct. We've been using
a single ModuleSP to track "the" old module, and this change switches
to using a SmallVector of ModuleSP, which has a couple benefits:
- There are multiple codepaths which may discover an old module, and
this centralizes the code for how to handle multiples in one place,
in the Target code. With the single ModuleSP, each place that may
discover an old module is responsible for how it handles multiples,
and the current code is inconsistent (some code paths drop the first
old module, others drop the second).
- The API will be more natural for identifying old modules in routines
that work on sets, like ModuleList::ReplaceEquivalent (which I plan
on updating to report old module(s) in a subsequent change to fix a
bug).
I'm not convinced we can ever actually run into the case that multiple
old modules are found in the same GetOrCreateModule call, but I think
this change makes sense regardless, in light of the above.
When an old module is reported, Target::GetOrCreateModule calls
m_images.ReplaceModule, which doesn't allow multiple "old" modules; the
new code calls ReplaceModule for the first "old" module, and for any
subsequent old modules it logs the event and calls m_images.Remove.
Reviewed By: jingham
Differential Revision: https://reviews.llvm.org/D89156
Current user_id_t format is:
63{isDebugTypes} 62..32{dwo || 7fffffff}
31..0 {die_offset}
while current DIERef format is (I have made up the bit positions but the
field widths do match):
63{m_section==isDebugTypes} 62{m_dwo_num_valid} 61..32{m_dwo_num}
31..0 {m_die_offset}
Proposing to change user_id_t to:
63{isDebugTypes} 62{dwo_is_valid} 61..32{dwo; 0 if !valid}
31..0 {die_offset}
There is no benefit of having 31-bits wide dwo_num in user_id_t when it
gets converted to 30-bits width in DIERef.
This patch is for future DWZ patchset which extends the dwo_is_valid bit
into a 2-bit field (normal, DWO, DWZ, DWZcommon) so that both user_id_t
and DIERef can be changed then the same way.
It would be best to somehow unify user_id_t and DIERef but I do not plan
to do that. user_id_t should probably remain a number for the Python API
compatibility while there still needs to be some class with all the
methods to access it.
SymbolFileDWARF::GetDwpSymbolFile() and SymbolFileDWARF::GetDIE use
0x3fffffff for DWP but that does not clash:
formerly:
31bits32..62:0x7fffffff = normal unit / not any DWO
31bits32..62:0x3fffffff = DWP
31bits32..62:others = DWO unit number
after this patch:
bit62=0 30bits32..61:any = normal unit / not any DWO
bit62=1 30bits32..61:0x3fffffff = DWP
bit62=1 30bits32..61:others = DWO unit number
Differential Revision: https://reviews.llvm.org/D90413
SymbolFileDWARF::GetTypes was not handling dwo correctly. The fix is
simple -- adding a GetNonSkeletonUnit call -- but I've snuck in a small
refactor as well.
Debug server is already launched by prep_debug_monitor_and_inferior. The
second seems to have been benign so far, but after 8cc49bec2 this test
started failing frequently on GreenDragon, and this is the only unusual
thing about it.
The class only supports a single DWARF unit (needed for my new test), and it
reimplements chunks of object and symbol file classes. We can just make it use
the real thing, save some LOC and get the full feature set.
Differential Revision: https://reviews.llvm.org/D90393
The intention is not to allow stop-hook commands to query the
user, so this is correct. It also works around a deadlock in
switching to the Python Session to execute python based commands
in the stop hook when the Debugger stdin is backed by a FILE *.
Differential Revision: https://reviews.llvm.org/D90332
This preprocessor define was meant to be used to conditionally include VCSVersion.inc. However, the define was always set, and it was the content of the header that was conditionally generated. Therefore HAVE_VCS_VERSION_INC should be cleaned up.
Reviewed By: gribozavr2, MaskRay
Differential Revision: https://reviews.llvm.org/D84623
This fixes an flakyness is all gdb-remote tests. These tests have been
(mildly) flaky since we started using "localhost" instead of 127.0.0.1
in the test suite. The reason is that lldb-server needs to create two
sockets (v4 and v6) to listen for localhost connections. The algorithm
it uses first tries to select a random port (bind(localhost:0)) for the
first address, and then bind the same port for the second one.
The creating of the second socket can fail as there's no guarantee that
port will be available -- it seems that the (linux) kernel tries to
choose an unused port for the first socket (I've had to create thousands
of sockets to reproduce this reliably), but this can apparantly fail
when the system is under load (and our test suite creates a _lot_ of
sockets).
The socket creationg operation is considered successful if it creates at
least one socket is created, but the test harness has no way of knowing
which one it is, so it can end up connecting to the wrong address.
I'm not aware of a way to atomically create two sockets bound to the
same port. One way to fix this would be to make lldb-server report the
address is it listening on instead of just the port. However, this would
be a breaking change and it's not clear to me that's worth it (the
algorithm works pretty well under normal circumstances).
Instead, this patch sidesteps that problem by using "reverse"
connections. This way, the test harness is responsible for creating the
listening socket so it can pass the address that it has managed to open.
It also results in much simpler code overall.
To preserve test coverage for the named pipe method, I've moved the
relevant code to a dedicated test. To avoid original problem, this test
passes raw addresses (as obtained by getaddrinfo(localhost)) instead of
"localhost".
Differential Revision: https://reviews.llvm.org/D90313
We're no longer convinced that this is needed and we have no test
coverage to disprove that. Backing out of this change until we're
convinced otherwise.
Make it possible to use a relative path in command script import to the
location of the file being sourced. This allows the user to put Python
scripts next to LLDB command files and importing them without having to
specify an absolute path.
To enable this behavior pass `-c` to `command script import`. The
argument can only be used when sourcing the command from a file.
rdar://68310384
Differential revision: https://reviews.llvm.org/D89334
The number of resumes should always be positive to let's make this an
unsigned everywhere. Also remove the unused 'localhost' parameter from
ConvertArgumentsForLaunchingInShell.
Replace the inline x86 watchpoint handling code with the reusable
NativeRegisterContextWatchpoint_x86. Implement watchpoint support
in NativeThreadFreeBSD and SIGTRAP handling for watchpoints.
Un-skip all concurrent_events tests as they pass with the new plugin.
Differential Revision: https://reviews.llvm.org/D90102
The statement that lldb-server can handle
decimal and hex numbers is misleading.
(it can only handle hex with 0x prefix)
Mentioning non decimal numbers at all
is just creating more confusion for anyone
who tries to use them with lldb-server.
Differential Revision: https://reviews.llvm.org/D89383
TestQuoting's different test methods all build their own test binaries but
we can just reuse the same test binary by merging all asserts into one method.
This reduces the test runtime from 8 seconds to 4 seconds on my machine.
This also removes the ability to have partial failures in this test, but given
how rarely this code is touched this seems like a fair tradeoff (and we will be
able to re-add this feature once we updated our test framework).
Some other small changes:
* Fixed that we cleanup "stdout.txt" instead of "output.txt" in the cleanup.
* Fixed some formatting issues.
* Call `build` instead of directly calling `buildDefault`.
clang supports option -fsplit-machine-functions and this test checks if the
backtraces are sane when functions are split.
With -fsplit-machine-functions, a function with profiles can get split into 2
parts, the original function containing hot code and a cold part as determined
by the profile info and the cold cutoff threshold.. The cold part gets the
".cold" suffix to disambiguate its symbol from the hot part and can be placed
arbitrarily in the address space.
This test checks if the back-trace looks correct when the cold part is executed.
Differential Revision: https://reviews.llvm.org/D90081
Displaying large packed bitfields did not work if one was accessing them
through a pointer, and he used the "->" notation ("[0]." notation is
fine). The reason for that is that implicit dereference in -> is plumbed
all the way down to ValueObjectChild::UpdateValue, where the process of
fetching the child value was forked for this flag. The bitfield
"sliding" code was implemented only for the branch which did not require
dereferencing.
This patch restructures the function to avoid this mistake. Processing
now happens in two stages.
- first the parent is dereferenced (if needed)
- then the child value is computed (this step includes sliding and is
common for both branches)
Differential Revision: https://reviews.llvm.org/D89236
Ensure that xs_xstate_bv is set correctly before calling
WriteRegisterSet(). The bit can be clear if the relevant registers
were at their initial state when they were read, and it needs to be set
in order to apply changes from the XState structure.
Differential Revision: https://reviews.llvm.org/D90105
Reset registers to their 'initial' state instead of a semi-random
pattern in write tests. While the latter might have been helpful
while debugging failures (i.e. to distinguish unmodified registers
from mistakenly written zeroes), the former makes it possible to test
whether xstate_bv field is written correctly when using XSAVE.
With this change, the four relevant tests start failing on NetBSD
without D90105.
Differential Revision: https://reviews.llvm.org/D90114
Unify the x86 regset API to use XStateRegSet for all FPU registers,
therefore eliminating the legacy API based on FPRegSet. This makes
the code a little bit simpler but most notably, it provides future
compatibility for register caching.
Since the NetBSD kernel takes care of providing compatibility with
pre-XSAVE processors, PT_{G,S}ETXSTATE can be used on systems supporting
only FXSAVE or even plain FSAVE (and unlike PT_{G,S}ETXMMREGS, it
clearly indicates that XMM registers are not supported).
Differential Revision: https://reviews.llvm.org/D90034
As mentioned in the comment inside the code, the Intel documentation
states that the internal CPU buffer is flushed out to RAM only when tracing is
disabled. Otherwise, the buffer on RAM might be stale.
This diff disables tracing when the trace buffer is going to be read. This is a
quite safe operation, as the reading is done when the inferior is paused at a
breakpoint, so we are not losing any packets because there's no code being
executed.
After the reading is finished, tracing is enabled back.
It's a bit hard to write a test for this now, but Greg Clayton and I will
refactor the PT support and writing tests for it will be easier. However
I tested it manually by doing a script that automates
the following flow
```
(lldb) b main
Breakpoint 1: where = a.out`main + 15 at main.cpp:4:7, address = 0x000000000040050f
(lldb) r
Process 3078226 stopped
* thread #1, name = 'a.out', stop reason = breakpoint 1.1
frame #0: 0x000000000040050f a.out`main at main.cpp:4:7
(lldb) processor-trace start
(lldb) b 5
Breakpoint 2: where = a.out`main + 22 at main.cpp:5:12, address = 0x0000000000400516
(lldb) c
Process 3078226 resuming
Process 3078226 stopped
* thread #1, name = 'a.out', stop reason = breakpoint 2.1
frame #0: 0x0000000000400516 a.out`main at main.cpp:5:12
(lldb) processor-trace show-instr-log
thread #1: tid=3078226
0x40050f <+15>: movl $0x0, -0x8(%rbp)
>>> Before, some runs of the script up to this point lead to empty traces
(lldb) b 6
Breakpoint 3: where = a.out`main + 42 at main.cpp:6:14, address = 0x000000000040052a
(lldb) c
Process 3092991 resuming
Process 3092991 stopped
* thread #1, name = 'a.out', stop reason = breakpoint 3.1
frame #0: 0x000000000040052a a.out`main at main.cpp:6:14
(lldb) processor-trace show-instr-log thread #1: tid=3092991
0x40050f <+15>: movl $0x0, -0x8(%rbp)
0x400516 <+22>: movl $0x0, -0xc(%rbp)
0x40051d <+29>: cmpl $0x2710, -0xc(%rbp) ; imm = 0x2710
0x400524 <+36>: jge 0x400546 ; <+70> at main.cpp
0x400524 <+36>: jge 0x400546 ; <+70> at main.cpp
>>> The trace was re-enabled correctly and includes the instruction of the
first reading.
```
Those instructions correspond to these lines
```
3 int main() {
4 int z = 0;
5 for (int i = 0; i < 10000; i++) {
6 z += fun(z)
...
```
Differential Revision: https://reviews.llvm.org/D85241
For performance reasons the reproducers don't copy the files captured by
the file collector eagerly, but wait until the reproducer needs to be
generated.
This is a problematic when LLDB crashes and we have to do all this
signal-unsafe work in the signal handler. This patch uses a similar
trick to clang, which has the driver invoke a new cc1 instance to do all
this work out-of-process.
This patch moves the writing of the mapping file as well as copying over
the reproducers into a separate process spawned when lldb crashes.
Differential revision: https://reviews.llvm.org/D89600
We were returning the default constructed unique_pointer from
TypeSystem.h for which the compiler does not have a definition. Move the
implementation into the cpp file.
This patch redesigns the Target::GetUtilityFunctionForLanguage API:
- Use a unique_ptr instead of a raw pointer for the return type.
- Wrap the result in an llvm::Expected instead of using a Status object as an I/O parameter.
- Combine the action of "getting" and "installing" the UtilityFunction as they always get called together.
- Pass std::strings instead of const char* and std::move them where appropriate.
There's more room for improvement but I think this tackles the most
prevalent issues with the current API.
Differential revision: https://reviews.llvm.org/D90011
Split the current NetBSD watchpoint implementation for x86 into Utility,
and revamp it to improve readability. This code is meant to be used
as a common class for all x86 watchpoint implementation, particularly
these on FreeBSD and Linux.
The code uses global watchpoint enable bits, as required by the NetBSD
kernel. If it ever becomes necessary for any platform to use local
enable bits instead, this can be trivially abstracted out.
The code also postpones clearing DR6 until a new different watchpoint
is being set in place of the old one. This is necessary since LLDB
repeatedly reenables watchpoints on all threads, by clearing
and restoring them. When DR6 is cleared as a part of that, then pending
events on other threads can no longer be associated with watchpoints
correctly.
Differential Revision: https://reviews.llvm.org/D89874
The UtilityFunction ctor was dropping the text argument. Probably for
that reason ClangUtilityFunction was setting the parent's member
directly instead of deferring to the parent ctor. Also change the
signatures to take strings which are std::moved in place.
This patch completes https://reviews.llvm.org/D83560. Now that the
compiler can emit `DW_OP_implicit_value` into DWARF expressions, lldb
needed to learn reading these opcodes for variable inspection and
expression evaluation.
This implicit location descriptor specifies an immediate value with two
operands: the length (ULEB128) followed by a block representing the value
in the target memory representation.
rdar://67406091
Differential revision: https://reviews.llvm.org/D89842
Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
In a new Range class was introduced to simplify and the Disassembler API
and reduce duplication. It unintentionally broke the
SBFrame::Disassemble functionality because it unconditionally converts
the number of instructions to a Range{Limit::Instructions,
num_instructions}. This is subtly different from the previous behavior,
where now we're passing a Range and assume it's valid in the callee, the
original code would propagate num_instructions and the callee would
compare the value and decided between disassembling instructions or
bytes.
Unfortunately the existing tests was not particularly strict:
disassembly = frame.Disassemble()
self.assertNotEqual(len(disassembly), 0, "Disassembly was empty.")
This would pass because without this patch we'd disassemble zero
instructions, resulting in an error:
(lldb) script print(lldb.frame.Disassemble())
error: error reading data from section __text
Differential revision: https://reviews.llvm.org/D89925
This test checks that the output of `SBTarget.GetDescription()` contains the
substrings `'a.out', 'Target', 'Module', 'Breakpoint'` in that order. This test
is currently failing on Apple simulators as apparently 'Module' can't be found
in the output after 'Target".
The reason for that is that the actual output of `SBTarget.GetDescription()` looks like this:
```
Target
Module /build/path/lldb-test-build.noindex/python_api/target/TestTargetAPI.test_get_description_dwarf/a.out
0x7ff2b6d3f990: ObjectFileMachO64, file = /build/path/lldb-test-build.noindex/python_api/target/TestTargetAPI.test_get_description
[...]
0x7ff307150000: BreakpointList with 0 Breakpoints:
<LLDB module output repeats for each loaded module>
```
Clearly the string order should be `'Target', 'Module', 'a.out', 'Breakpoint'`.
However, LLDB is also a bunch of system shared libraries (libxpc.dylib,
libobjc.A.dylib, etc.) when *not* running against a simulator, we end up
unintentionally finding the `'Target', 'Module', 'Breakpoint'` substrings in the
trailing descriptions of the system modules. When running against a simulator we
however don't load shared system libraries.
This patch just moves the substrings in the correct order to make this test pass
without having any shared library modules in the description output.
Reviewed By: JDevlieghere
Differential Revision: https://reviews.llvm.org/D89698
The Darwin builder currently assumes in `getArchCFlags` that the passed `arch`
value is an actual string it can string.join with vendor/os/version/env strings:
```
triple = '-'.join([arch, vendor, os, version, env])
```
However this is not true for most tests as we just pass down the `arch=None`
default value from `TestBase.build`. This causes that if we actually end up in
this function we just error out when concatenating `None` with the other actual
strings of vendor/os/version/env. What we should do instead is check that if
there is no test-specific architecture that we fall back to the configuration's
architecture value.
It seems we already worked around this in `builder.getArchSpec` by explicitly
falling back to the architecture specified in the configuration.
This patch just moves this fallback logic to the top `build` function so that it
affects all functions called from `TestBase.build`.
Reviewed By: JDevlieghere
Differential Revision: https://reviews.llvm.org/D89056
The existing help text was very terse and was missing several important
options. In the new version, I add a short description of each option
and a slightly longer description of the tool as a whole.
The new option list does not include undocumented no-op options:
--debug and --verbose. It also does not include undocumented short
aliases for long options, with two exceptions: -h, because it's
well-known; and -S (--setsid), as it's used in one test. Using these
options will now produce an error. I believe that is acceptable as users
aren't generally invoking lldb-server directly, and the only way to
learn about the short aliases was by looking at the source.
Differential Revision: https://reviews.llvm.org/D89477
In a discussion with Jim last week we came to the realization that often
we get asked about things that might not be documented on the website,
but that have been pretty well explained elsewhere. In those situations
it's often easier to quickly answer the question than searching for that
presentation you gave 3 years ago if you remember at all.
This often results in us having to answer the same questions over and
over again. We could add the questions and their answer to the website,
but that means we (1) have to duplicate the work and (2) now have to
maintain it.
A more efficient solution is to add a page with external resources with
the caveat that they might be outdated. That's exactly the purpose of
this patch.
I've added a few links that came to mind, but I don't want to be the
arbiter of what should and should not be included. I'd hope that over
time the community can crowd-source the best resources.
Differential revision: https://reviews.llvm.org/D89215
Add a nul byte to the stream in CommunicationKDP::CheckForPacket
before we send the GetData() to a Log::Printf as a c-str. Avoids
a crash when logging kdp communications and memory layout isn't
in your favor.
Renamed ThreadIntelPT to TreaceThread, making it a top-level class. I noticed that this class can and shuld work for any trace plugin and there's nothing intel-pt specific in it.
With that TraceThread change, I was able to move most of the json file parsing logic to the base class TraceSessionFileParser, which makes adding new plug-ins easier.
This originally was part of https://reviews.llvm.org/D89283
Differential Revision: https://reviews.llvm.org/D89408
LookupAddress makes no sense for DWARFTypeUnit.
Also make GetNonSkeletonUnit to preserve the called type.
Differential Revision: https://reviews.llvm.org/D89646
There were invalid DIE references which nobody used. If LLDB starts to
report invalid DIE references it would lock up (mutex lock).
These invalid DIE references are there since initial check-in by:
https://reviews.llvm.org/D83302
In lldb, explicitly set the "option() honors normal variables" CMake policy. This applies for
standalone lldb builds and matches what llvm, clang, etc do. This prevents potentially unwanted
clearing of variables like `LLVM_ENABLE_WARNINGS`, and also prevents unnecessary build warnings.
See: https://cmake.org/cmake/help/latest/policy/CMP0077.html
Differential Revision: https://reviews.llvm.org/D89614
The test reorders the basic blocks to be dis-contiguous in the address space and checks if the back trace contains the right symbol.
Reviewed By: labath
Differential Revision: https://reviews.llvm.org/D89179
This patch also avoids hardcoding the clang options, which makes it
less likely for them to become out-of-date.
rdar://problem/63791367+66927829
Differential Revision: https://reviews.llvm.org/D89428
When opening a minidump, we might discover that it reports a UUID for a
module that doesn't match the build ID, but rather a hash of the .text
section (according to either of two different hash functions, used by
breakpad and Facebook respectively). The current logic searches for a
module by filename only to check the hash; this change updates it to
first search by directory+filename. This is important when the
directory specified in the minidump must be interpreted relative to a
user-provided sysoort, as the leaf directory won't be in the search path
in that case.
Also add a regression test; without this change, module validation fails
because we have just the placeholder module which reports as its path
the platform path in the minidump.
Reviewed By: clayborg
Differential Revision: https://reviews.llvm.org/D89155
Implement initial support for watching thread creation and termination.
Update ptrace() calls to correctly indicate requested thread.
Watchpoints are not supported yet.
This patch fixes at least multithreaded register tests.
Differential Revision: https://reviews.llvm.org/D89413
With a large dSYM over a slow home connection, the two minute timeout
would sometimes be exceeded, and we haven't seen instances of a
long timeout causing people any problems, so we're bumping it up.
640 seconds ought to be enough for anyone.
<rdar://problem/67759526>
XFAIL nodefaultlib.cpp on darwin - the test does not pass there
XFAIL TestGdbRemoteMemoryAllocation on windows - memory is allocated
with incorrect permissions
Add a framework for reading/writing extended register sets via
PT_GETXSTATE/PT_GETXSTATE_INFO/PT_SETXSTATE, and use it to support
YMM0..YMM15. The code is prepared to handle arbitrary XSAVE extensions,
including correct offset handling.
This fixes Shell/Register/*ymm* tests.
Differential Revision: https://reviews.llvm.org/D89193
This patch adds support for the _M and _m gdb-remote packets, which
(de)allocate memory in the inferior. This works by "injecting" a
m(un)map syscall into the inferior. This consists of:
- finding an executable page of memory
- writing the syscall opcode to it
- setting up registers according to the os syscall convention
- single stepping over the syscall
The advantage of this approach over calling the mmap function is that
this works even in case the mmap function is buggy or unavailable. The
disadvantage is it is more platform-dependent, which is why this patch
only works on X86 (_32 and _64) right now. Adding support for other
linux architectures should be easy and consist of defining the
appropriate syscall constants. Adding support for other OSes depends on
the its ability to do a similar trick.
Differential Revision: https://reviews.llvm.org/D89124
Add a test to verify that 'register read' and 'register write' commands
work correctly in a multithreaded program, in particular that they read
or write registers for the correct thread. The tests use locking
to ensure that events are serialized and the test can execute reliably.
Differential Revision: https://reviews.llvm.org/D89248
Currently one can redefine a persistent variable and LLDB will just silently
ignore the second definition:
```
(lldb) expr int $i = 1
(lldb) expr int $i = 2
(lldb) expr $i
(int) $i = 1
```
This patch makes this an error and rejects the expression with the second
definition.
A nice follow up would be to refactor LLDB's persistent variables to not just be
a pair of type and name, but also contain some way to obtain the original
declaration and source code that declared the variable. That way we could
actually make a full diagnostic as we would get from redefining a variable twice
in the same expression.
Reviewed By: labath, shafik, JDevlieghere
Differential Revision: https://reviews.llvm.org/D89310
Currently we only strip the Python extension when the file exists on
disk because we assumed that if it didn't exist it was a module.
However, with the change from D89334 this is no longer the case as we
want to be able to import a relative path to a .py as a module. Since we
always import a scripting module as a "python module" we should always
strip the extension if present.
Differential revision: https://reviews.llvm.org/D89352
the xcode project file for debugserver exists only to make my
life easier when I'm working only on debugserver and don't need
to build the rest of llvm/lldb. It had many build configurations
to reflect our old lldb xcode project file, which is long gone.
Removing them to simplify the configurations.
Specifically dropping CustomSwift-Debug, DebugClang, DebugPresubmission,
CustomSwift-Release, BuildAndIntegration. Keeping Debug & Release.
Link against CarouselServices on watchos, recognize the
WatchComplicationLaunch launch flag option when that framework
is available.
<rdar://problem/62473967>, <rdar://problem/61230088>
We are still implementing our own logic for this that looks for a VCS file in
the place where it was before the monorepo migration. This removes this logic
and just uses the CMake function that LLVM/Clang are using.
Reviewed By: JDevlieghere, kastiglione
Differential Revision: https://reviews.llvm.org/D88950
While debugging another bug I found out that we currently don't set any limit
for the number of diagnostics Clang emits. If a user does something that
generates a lot of errors (like including some long header file from within the
expression function), then we currently spam the LLDB output with potentially
thousands of Clang error diagnostics.
Clang sets a default limit of 20 errors, but given that LLDB is often used
interactively for small expressions I would say a limit of 5 is enough. The
limit is implemented as a setting, so if a user cares about seeing having a
million errors printed to their terminal then they can just increase the
settings value.
Reviewed By: shafik, mib
Differential Revision: https://reviews.llvm.org/D88889
RegisterInfo's `reg_name`/`reg_alt_name` fields are C-Strings and are supposed
to only be generated from a ConstString. The reason for that is that
`DynamicRegisterInfo::GetRegisterInfo` and
`RegInfoBasedABI::GetRegisterInfoByName` try to optimise finding registers by
name by only comparing the C string pointer values instead of the underlying
strings. This only works if both C strings involved in the comparison come from
a ConstString. If one of the two C strings doesn't come from a ConstString the
comparison won't work (and most likely will silently fail).
I added an assert in b0060c3a78 which checks that
both strings come from a ConstString. Apparently not all ABI plugins are
generating their register names via ConstString, so this code is now not just
silently failing but also asserting.
In D88375 we did a shady fix for the MIPS plugins by just copying the
ConstString setup code to that plugin, but we still need to fix ABISysV_arc,
ABISysV_ppc and ABISysV_ppc64 plugins.
I would say we just fix the remaining plugins by removing the whole requirement
to have the register names coming from ConstStrings. I really doubt that we
actually save any time with the whole ConstString search trick (searching ~50
strings that have <4 characters doesn't sound more expensive than calling the
really expensive ConstString constructor + comparing the same amount of pointer
values). Also whatever small percentage of LLDB's runtime is actually spend in
this function is anyway not worth the complexity of this approach.
This patch just removes all this and just does a normal string comparison.
Reviewed By: JDevlieghere, labath
Differential Revision: https://reviews.llvm.org/D88490
That's supposed to be used to implement things such as `settings set target.run-args{basename==test&&arch==x86_64} arg1`
but it's not actually fully implemented or tested anywhere.
Reviewed By: JDevlieghere
Differential Revision: https://reviews.llvm.org/D88910
This patch adds several build system targets that run the normal test suite but
against the Watch/TV/iPhone simulators.
Reviewed By: JDevlieghere
Differential Revision: https://reviews.llvm.org/D89224
It seems that if codesigning the test executables with the
`com.apple.private.security.no-sandbox` entitlement then the simulator refuses
to launch them and every test fails with `Process launch failed: process exited
with status -1 (no such process.)`.
This patch checks if we're trying to run the test suite on the simulator and
then avoids signing the executable with `no-sandbox`.
Reviewed By: JDevlieghere
Differential Revision: https://reviews.llvm.org/D89052
If the SDK name passed to dotest can't be found by `xcrun` we silently fall back
to the default SDK. This leads to rather cryptic errors being reported later on
when linking the actual test executables.
Instead just directly log and abort when this situation is encountered and
inform the user about the invalid argument.
Reviewed By: JDevlieghere
Differential Revision: https://reviews.llvm.org/D89053
When running the test suite against the Watch/AppleTV simulator we currently hitting
the unimplemented parts of PlatformDarwin for the respective simulator platforms.
This just adds the respective switch cases.
This whole code path depends on having a valid Target, so can't just unittest this code
without refactoring it. So instead this is tested by just running the testsuite against
the respective simulators (which is how I found this).
Reviewed By: aprantl
Differential Revision: https://reviews.llvm.org/D89106
Raphael Isemann