llvm's json parser supports uint64_t, so let's better use it for the
packets being sent between lldb and lldb-server instead of using int64_t
as an intermediate type, which might be error-prone.
A previous commit enabled LLDB to be able to debug a program launched via ld: https://reviews.llvm.org/D108061.
This commit adds the ability to debug a program launched via ld when it happens during an exec into the dynamic loader. There was an issue where after the exec we would locate the rendezvous structure right away but it didn't contain any valid values and we would try to set the dyanamic loader breakpoint at address zero. This patch fixes that and adds a test.
Differential Revision: https://reviews.llvm.org/D125253
I'm refactoring IntelPTThreadTrace into IntelPTSingleBufferTrace so that it can
both single threads or single cores. In this diff I'm basically renaming the
class, moving it to its own file, and removing all the pieces that are not used
along with some basic cleanup.
Differential Revision: https://reviews.llvm.org/D124648
This updates the documentation of the gdb-remote protocol, as well as the help messages, to include the new --per-core-tracing option.
Differential Revision: https://reviews.llvm.org/D124640
See [[ https://github.com/llvm/llvm-project/issues/55040 | issue 55040 ]] where static members of classes declared in the anonymous namespace are incorrectly returned as member fields from lldb::SBType::GetFieldAtIndex(). It appears that attrs.member_byte_offset contains a sentinel value for members that don't have a DW_AT_data_member_location.
Reviewed By: labath
Differential Revision: https://reviews.llvm.org/D124409
IIUC, the purpose of CopyUniqueClassMethodTypes is to link together
class definitions in two compile units so that we only have a single
definition of a class. It does this by adding entries to the die_to_type
and die_to_decl_ctx maps.
However, the direction of the linking seems to be reversed. It is taking
entries from the class that has not yet been parsed, and copying them to
the class which has been parsed already -- i.e., it is a very
complicated no-op.
Changing the linking order allows us to revert the changes in D13224
(while keeping the associated test case passing), and is sufficient to
fix PR54761, which was caused by an undesired interaction with that
patch.
Differential Revision: https://reviews.llvm.org/D124370
On arm64 targets, when the crashing pc is 0, the caller
frame can be found by looking at $lr, but the crash
reports don't use that trick to show the actual crashing
frame. This patch adds that stack frame that lldb shows.
Also fix an issue where some register names were printed
as having a prefix of 'None'.
Differential Revision: https://reviews.llvm.org/D125042
rdar://92631787
When picking the UnwindPlan row to use to backtrace,
off of the zeroth frame, decrement the return pc so
we're in the address range of the call instruction.
If this is a noretrun function call, the instruction
at the "return address" is likely an entirely different
basic block with possibly very different unwind rules,
and this can cause the backtrace to be incorrect.
Differential Revision: https://reviews.llvm.org/D124957
rdar://84651805
Currently, debugserver has a test to check if it was launched in
translation. The intent was to cover the case where an x86_64
debugserver attempts to control an arm64/arm64e process, returning
an error. However, this check also covers the case where users
are attaching to an x86_64 process, exiting out before attempting
to hand off control to the translated debugserver at
`/Library/Apple/usr/libexec/oah/debugserver`.
This diff delays the debugserver translation check until after
determining whether to hand off control to
`/Library/Apple/usr/libexec/oah/debugserver`. Only when the
process is not translated and thus has not been handed off do we
check if the debugserver is translated, erroring out in that case.
Reviewed By: jasonmolenda
Differential Revision: https://reviews.llvm.org/D124814
Currently, ppc64le and ppc64 (defaulting to big endian) have the same
descriptor, thus the linear scan always return ppc64le. Handle that through
subtype.
This is a recommit of f114f00948 with a new test
setup that doesn't involves (unsupported) corefiles.
Differential Revision: https://reviews.llvm.org/D124760
In UnwindAssemblyInstEmulation we correctly recognize when a LDP
restores the fp & lr in an epilogue, and mark them as having the
caller's contents now, but we don't update the CFA register rule
at that point to indicate that the CFA is now calculated in terms
of $sp. This doesn't impact the backtrace because the register
contents are all <same> now, but it can confuse the stepper when
the StackID changes mid-epilogue.
Differential Revision: https://reviews.llvm.org/D124492
rdar://92064415
If LLDB index cache is enabled and everything is cached, then loading of debug
info is essentially single-threaded, because it's done from PreloadSymbols()
called from GetOrCreateModule(), which is called from a loop calling
LoadModuleAtAddress() in DynamicLoaderPOSIXDYLD. Parallelizing the entire
loop could be unsafe because of GetOrCreateModule() operating on a module
list, so instead move only the PreloadSymbols() call to Target::ModulesDidLoad()
and parallelize there, which should be safe.
This may greatly reduce the load time if the debugged program uses a large
number of binaries (as opposed to monolithic programs where this presumably
doesn't make a difference). In my specific case of LibreOffice Calc this reduces
startup time from 6s to 2s.
Differential Revision: https://reviews.llvm.org/D122975
As a preparation for parallelizing loading of symbols (D122975),
it is necessary to use just one thread pool to avoid using
a thread pool from inside a task of another thread pool.
Differential Revision: https://reviews.llvm.org/D123226
This patch adds a function to check if lldb is running in an interactive
debug session. Currently this API only works on macOS. It's expected to
be used in combination with Host::OpenFileInExternalEditor.
Differential revision: https://reviews.llvm.org/D124872
When writing out the session transcript, print output to the
asynchronous debugger stream to prevent it from potentially interleaving
with other output.
Differential revision: https://reviews.llvm.org/D124873
This adds a setting (`target.max-children-depth`) that will provide a default value for the `--depth` flag used by `expression` and `frame variable`.
The new setting uses the same default that's currently fixed in source: `UINT32_MAX`.
This provides two purposes:
1. Allowing downstream forks to provide a customized default.
2. Allowing users to set their own default.
Following `target.max-children-count`, a warning is emitted when the max depth is reached. The warning lets users know which flags or settings they can customize. This warning is shown only when the limit is the default value.
rdar://87466495
Differential Revision: https://reviews.llvm.org/D123954
Instead of building a set twice for optional and required,
build a set for each while walking the options once.
Then take advantage of set being sorted meaning we don't
have to enforce the upper/lower order ourselves.
Just cleaned up the formatting on the later loops.
Combined the if conditions and used a single line if.
Depends on D123501
Reviewed By: jingham
Differential Revision: https://reviews.llvm.org/D123502
Use llvm::enumerate, remove an unused arg name stream and
replace repeated uses of indexing to get the option def.
We could use map instead of multimap but I'm not 100% that
would be NFC. All short options should be unique in theory.
Depends on D123500
Reviewed By: JDevlieghere
Differential Revision: https://reviews.llvm.org/D123501
This adds a few targeted tests to make sure that when refactoring
this function later I don't break these properties.
Some are tested in passing elsewhere but this makes it more
obvious what went wrong when it fails.
This doesn't cover everything the function does, I couldn't
find any examples that would exercise some of the code.
Reviewed By: jingham
Differential Revision: https://reviews.llvm.org/D123500
This reverts commit f114f00948.
Due to hitting an assert on our lldb bots:
https://lab.llvm.org/buildbot/#/builders/96/builds/22715
../llvm-project/lldb/source/Plugins/Process/elf-core/ThreadElfCore.cpp:170:
virtual lldb::RegisterContextSP ThreadElfCore::CreateRegisterContextForFrame(
lldb_private::StackFrame *): Assertion `false && "Architecture or OS not supported"' failed.
Currently, ppc64le and ppc64 (defaulting to big endian) have the same
descriptor, thus the linear scan always return ppc64le. Handle that through
subtype.
Differential Revision: https://reviews.llvm.org/D124760
Make GetSharedModuleWithLocalCache consider the device support
directory. In the past we only needed the device support directory to
debug remote processes. Since the introduction of Apple Silicon and
Rosetta this stopped being true.
When debugging a Rosetta process on macOS we need to consider the
Rosetta expanded shared cache. This patch and it dependencies move that
logic out of PlatfromRemoteDarwinDevice into a new abstract class called
PlatfromDarwinDevice. The new platform sit in between PlatformDarwin and
PlatformMacOSX and PlatformRemoteDarwinDevice and has all the necessary
logic to deal with the device support directory.
Technically I could have moved everything in PlatfromDarwinDevice into
PlatfromDarwin but decided that this logic is sufficiently self
contained that it warrants its own abstraction.
rdar://91966349
Differential revision: https://reviews.llvm.org/D124801
In order to open perf events per core, we need to first get the list of
core ids available in the system. So I'm adding a function that does
that by parsing /proc/cpuinfo. That seems to be the simplest and most
portable way to do that.
Besides that, I made a few refactors and renames to reflect better that
the cpu info that we use in lldb-server comes from procfs.
Differential Revision: https://reviews.llvm.org/D124573
Skip on linux+arm for now until I can try to repo the setup of the
lldb-arm-ubuntu bot. The name of the binary in argv[0] was not
able to be retrieved here; if the compiler's codegen had it stored
in a caller saved register, because it's not needed at this point,
it may not be retreivable.
When looking for a variable location in a DWARF location list,
we search the list of ranges to find one that includes the pc.
With a function mid-stack, the "pc" is the return pc instead of
the call instruction, and in optimized code this can be another
function or a different basic block (with different variable
locations). Back up the "pc" value mid-stack to find the correct
location list entry.
Differential Revision: https://reviews.llvm.org/D124597
rdar://63903416
UniqueCStringMap<T> objects are a std::vector<UniqueCStringMap::Entry> objects where the Entry object contains a ConstString + T. The values in the vector are sorted first by ConstString and then by the T value. ConstString objects are simply uniqued "const char *" values and when we compare we use the actual string pointer as the value we sort by. This caused a problem when we saved the symbol table name indexes and debug info indexes to disk in one process when they were sorted, and then loaded them into another process when decoding them from the cache files. Why? Because the order in which the ConstString objects were created are now completely different and the string pointers will no longer be sorted in the new process the cache was loaded into.
The unit tests created for the initial patch didn't catch the encoding and decoding issues of UniqueCStringMap<T> because they were happening in the same process and encoding and decoding would end up createing sorted UniqueCStringMap<T> objects due to the constant string pool being exactly the same.
This patch does the sort and also reserves the right amount of entries in the UniqueCStringMap::m_map prior to adding them all to avoid doing multiple allocations.
Added a unit test that loads an object file from yaml, and then I created a cache file for the original file and removed the cache file's signature mod time check since we will generate an object file from the YAML, and use that as the object file for the Symtab object. Then we load the cache data from the array of symtab cache bytes so that the ConstString "const char *" values will not match the current process, and verify we can lookup the 4 names from the object file in the symbol table.
Differential Revision: https://reviews.llvm.org/D124572
We've seen very occasional crashes that we can only explain by
simultaneous access to the ThreadPlanStackMap, so I'm adding a
mutex to protect it.
Differential Revision: https://reviews.llvm.org/D124029
In commit ccf1469a4c lldb got its own generated Version.inc file, with
`LLDB_VERSION` macros. However, it used `LLDB_VERSION_PATCHLEVEL`
instead of the actually correct `LLDB_VERSION_PATCH`. Correct this.
Reviewed By: JDevlieghere
Differential Revision: https://reviews.llvm.org/D124672
I suspect that one of link or cl is found by shutil.which
and one isn't, hence the case difference. It doesn't really
matter for what the test is looking for.
This reverts commit d9247cc848.
With the Windows tests updated to expect .EXE suffixes. This changed
because shutil.which uses PATHEXT which will contain, amongst others,
"EXE".
Also I noticed the "." in ".exe" was the wildcard dot not literal
dot so I've escaped those.
In build.py we have our own find_executable that looks
a lot like the distutils one that I switched to shutil.which.
This find_executable isn't quite the same as shutil.which
so I've refactored it to call that in the correct way.
Note that the path passed to shutil.which is in the form that
PATH would be, meaning separators are allowed.
```
>>> shutil.which("gcc", path="/home/david.spickett:/bin")
'/bin/gcc'
```
We just need to make sure it doesn't ignore the existing PATH
and normalise the result if it does find the binary.
The .exe extension is automatically added to the binary name
if we are on Windows.
Depends on D124601
Reviewed By: JDevlieghere
Differential Revision: https://reviews.llvm.org/D124604
distutils is deprecated and shutil.which is the suggested
replacement for this function.
https://peps.python.org/pep-0632/#migration-advicehttps://docs.python.org/3/library/shutil.html#shutil.which
It was added in Python3.3 but given that we're already using
shutil.which elsewhere I think this is ok/no worse than before.
We do have our own find_executable in lldb/test/Shell/helper/build.py
but I'd rather leave that as is for now. Also we have our own versions
of which() but again, a change for another time.
This work is part of #54337.
Reviewed By: JDevlieghere
Differential Revision: https://reviews.llvm.org/D124601
This patch fixes a crash when using process launch -t to launch the
inferior from a TTY. The issue is that on Darwin, Host.mm is calling
ConnectionFileDescriptor::Connect without a socket_id_callback_type. The
overload passes nullptr as the function ref, which gets called
unconditionally as the socket_id_callback.
One potential way to fix this is to change all the lambdas to include a
null check, but instead I went with an empty lambda.
Differential revision: https://reviews.llvm.org/D124535
FixAnyAddress is to be used when we don't know or don't care
whether we're fixing a code or data address.
By using FixAnyAddress over the others, you document that no
specific choice was made.
On all existing platforms apart from Arm Thumb, you could use
either FixCodeAddress or FixDataAddress and be fine. Up until
now I've chosen to use FixDataAddress but if I had
chosen to use FixCodeAddress that would have broken Arm Thumb.
Hence FixAnyAddress, to give you the "safest" option when you're
in generic code.
Uses of FixDataAddress in memory region code have been changed
to FixAnyAddress. The functionality is unchanged.
Reviewed By: omjavaid, JDevlieghere
Differential Revision: https://reviews.llvm.org/D124000
Fix escaping when launching in terminal with AppleScript. The invocation
we're building up is wrapped in single quotes when passed to bash and
wrapped in double quotes for AppleScript.
Here's an example invocation with the new escaping:
tell application "Terminal"
activate
do script "/bin/bash -c 'arch -arch arm64 'darwin-debug'
--unix-socket=/tmp/dL2jSh --arch=arm64 --working-dir
\"/private/tmp/with spaces\" --disable-aslr -- \"foo\"
\"bar\" \"baz\" ; echo Process exited with status $?';exit"
end tell
Previously we were using unescaped single quotes which resulted in the
whole bash invocation being passed in pieces. That works most of the
time but breaks when you have a space in your current working directory
for example.
rdar://91870763
Differential revision: https://reviews.llvm.org/D124568
Rather than looking up by offset - actually use the hash table to
perform faster lookup where possible. (for DWARFv4 DWP compilation units
the hash isn't in the header - it's in the root DIE, but to parse the
DIE you need the abbrev section and to get the abbrev section you need
the index - so in that case lookup by offset is required)
- Don't reset cur_line_offset to llvm::None when we don't have next_line_offset, because we may need to reuse it in new range after a code end.
- Don't use CombineConsecutiveEntriesWithEqualData for inline_site_sp->ranges, because that will combine consecutive entries with same data in the vector regardless of the entry's range. Originally, I thought that it only combine consecutive entries if adjacent entries' ranges are adjoining or intersecting with each other.
We dropped downstream support for Python 2 in the previous release. Now
that we have branched for the next release the window where this kind of
change could introduce conflicts is closing too. Remove Python 2 checks
from the test suite.
Differential revision: https://reviews.llvm.org/D124429
We dropped downstream support for Python 2 in the previous release. Now
that we have branched for the next release the window where this kind of
change could introduce conflicts is closing too. Start by getting rid of
Python 2 support in the Script Interpreter plugin.
Differential revision: https://reviews.llvm.org/D124429
The test was broken (in the sense that it was not testing what it was
supposed to test) in two ways:
- a Makefile refactor caused it to stop being built with
-flimit-debug-info
- clang's constructor homing changed the "home" of the type
This patch fixes the Makefile, and modifies the source code to produce
the same result with both type homing strategies. Due to constructor
homing I had to use a different implicitly-defined function for the test
-- I chose the assignment operator.
I also added some sanity checks to the test to ensure that the test is
indeed operating on limited debug info.
The driver can push a null ExecutionContext on to this stack,
and later calls to SBCommandInterpreter::HandleCommand which
don't specify an ExecutionContext can pull an entry from the
stack, resulting in settings that aren't applied.
Differential Revision: https://reviews.llvm.org/D111209
rdar://81489207
The last fix missed an import in one test file causing skipIfWindows attribute
can't be recognized.
I feel embarrassed to miss it. I have run all tests on Mac to make sure them
passing in this patch.
Differential Revision: https://reviews.llvm.org/D124479
Symbol on-demand feature is never tested on Windows so it is not a surprise
that we are getting Buildbot failure from Windows:
https://lab.llvm.org/buildbot/#/builders/83/builds/18228
This patch disables symbol on-demand feature on Windows. I will find a Windows
machine to test and re-enable symbol on-demand feature as follow-up.
Differential Revision: https://reviews.llvm.org/D124471
This diff introduces a new symbol on-demand which skips
loading a module's debug info unless explicitly asked on
demand. This provides significant performance improvement
for application with dynamic linking mode which has large
number of modules.
The feature can be turned on with:
"settings set symbols.load-on-demand true"
The feature works by creating a new SymbolFileOnDemand class for
each module which wraps the actual SymbolFIle subclass as member
variable. By default, most virtual methods on SymbolFileOnDemand are
skipped so that it looks like there is no debug info for that module.
But once the module's debug info is explicitly requested to
be enabled (in the conditions mentioned below) SymbolFileOnDemand
will allow all methods to pass through and forward to the actual SymbolFile
which would hydrate module's debug info on-demand.
In an internal benchmark, we are seeing more than 95% improvement
for a 3000 modules application.
Currently we are providing several ways to on demand hydrate
a module's debug info:
* Source line breakpoint: matching in supported files
* Stack trace: resolving symbol context for an address
* Symbolic breakpoint: symbol table match guided promotion
* Global variable: symbol table match guided promotion
In all above situations the module's debug info will be on-demand
parsed and indexed.
Some follow-ups for this feature:
* Add a command that allows users to load debug info explicitly while using a
new or existing command when this feature is enabled
* Add settings for "never load any of these executables in Symbols On Demand"
that takes a list of globs
* Add settings for "always load the the debug info for executables in Symbols
On Demand" that takes a list of globs
* Add a new column in "image list" that shows up by default when Symbols On
Demand is enable to show the status for each shlib like "not enabled for
this", "debug info off" and "debug info on" (with a single character to
short string, not the ones I just typed)
Differential Revision: https://reviews.llvm.org/D121631
TraceInstructionDumper::DumpInstructions was becoming too big, so I'm
refactoring it into smaller functions. I also made some static methods proper
instance methods to simplify calls. Other minor improvements are also done.
Differential Revision: https://reviews.llvm.org/D124064
A trace might contain events traced during the target's execution. For
example, a thread might be paused for some period of time due to context
switches or breakpoints, which actually force a context switch. Not only
that, a trace might be paused because the CPU decides to trace only a
specific part of the target, like the address filtering provided by
intel pt, which will cause pause events. Besides this case, other kinds
of events might exist.
This patch adds the method `TraceCursor::GetEvents()`` that returns the
list of events that happened right before the instruction being pointed
at by the cursor. Some refactors were done to make this change simpler.
Besides this new API, the instruction dumper now supports the -e flag
which shows pause events, like in the following example, where pauses
happened due to breakpoints.
```
thread #1: tid = 2717361
a.out`main + 20 at main.cpp:27:20
0: 0x00000000004023d9 leaq -0x1200(%rbp), %rax
[paused]
1: 0x00000000004023e0 movq %rax, %rdi
[paused]
2: 0x00000000004023e3 callq 0x403a62 ; std::vector<int, std::allocator<int> >::vector at stl_vector.h:391:7
a.out`std::vector<int, std::allocator<int> >::vector() at stl_vector.h:391:7
3: 0x0000000000403a62 pushq %rbp
4: 0x0000000000403a63 movq %rsp, %rbp
```
The `dump info` command has also been updated and now it shows the
number of instructions that have associated events.
Differential Revision: https://reviews.llvm.org/D123982
Update the online help text for breakpoint set to be
consistent with respect to the spelling of Objective-C
and fix a few space-related typos.
Differential revision: https://reviews.llvm.org/D124338
Applied clang-tidy modernize-use-override over LLDB and added it to the LLDB .clang-tidy config.
Differential Revision: https://reviews.llvm.org/D123340
Added implementation to support DWARF5 in monolithic mode.
Next step DWARF5 split dwarf support.
Reviewed By: maksfb
Differential Revision: https://reviews.llvm.org/D121876
The code needs more TLC, but for now I've tried making only the changes
that are necessary to get the tests passing -- postponing the more
invasive changes after I create a more comprehensive test.
In a couple of places I have changed the index-based element accesses to
name-based ones (as these are less sensitive to code perturbations). I'm
not sure why the code was using indexes in the first place, but I've
(manually) tested the change with various libc++ versions, and found no
issues with this approach.
Differential Revision: https://reviews.llvm.org/D124113
This patch replaces getargspec with getfullargspec in funcutils.py.
getargspec has been deprecated by python 11x release. This is
important to run LLDB testsuite in Windows/Arm64 platform
where Python native will be available from python release onwards.
Note: getfullargspec is not available in python 2
Reviewed By: labath
Differential Revision: https://reviews.llvm.org/D121786
Previously, I was assuming that S_DEFRANGE_SUBFIELD_REGISTERs are always in the
increasing order of offset_in_parent until I saw a counter example.
Using `std::map` so that they are sorted by offset_in_parent.
Differential Revision: https://reviews.llvm.org/D124061
Given that you'd never find empty string, just error.
Also add a test that an invalid expr generates an error.
Reviewed By: JDevlieghere
Differential Revision: https://reviews.llvm.org/D123793
This adjusts the path iteration - `paths` is a null-terminated sequence
of C strings, creating an array from a single contiguous buffer. We
would previously continue to iterate indefinitely as we did not check if
we had encountered the terminator.
Found by inspection.
Remove TestShell.test because it's failing on the bot with "this is a
non-interactive debug session, cannot get permission to debug
processes." The only thing that's special about this test is the shell
we're launching with. I need to do a bit of digging to understand why
that's causing this error.
rdar://91766931
When a variable is simple type and has 64 bits, the debug info may look like the following when targeting 32bit windows. The variable's content is split into two 32bits registers.
```
480 | S_LOCAL [size = 12] `x`
type=0x0013 (__int64), flags = param
492 | S_DEFRANGE_SUBFIELD_REGISTER [size = 20]
register = EAX, may have no name = true, offset in parent = 0
range = [0001:0073,+7), gaps = []
512 | S_DEFRANGE_SUBFIELD_REGISTER [size = 20]
register = ECX, may have no name = true, offset in parent = 4
range = [0001:0073,+7), gaps = []
```
Reviewed By: labath
Differential Revision: https://reviews.llvm.org/D122943
It fixes the following case:
```
0602 line 1 (+1)
0315 code 0x15 (+0x15)
0B2B code 0x20 (+0xB) line 2 (+1)
0602 line 3 (+1)
0311 code 0x31 (+0x11)
...
```
Inline ranges should have following mapping:
`[0x15, 0x20) -> line 1`
`[0x20, 0x31) -> line 2`
Inline line entries:
`0x15, line 1`, `0x20, line 2`, `0x31, line 3`.
Reviewed By: labath
Differential Revision: https://reviews.llvm.org/D123092
Port the two Process::PrintWarning functions to use the new diagnostic
events through Debugger::ReportWarning. I kept the wrapper function in
the process, but delegated the work to the Module. Consistent with the
current code, the Module ensures the warning is only printed once per
module.
Differential revision: https://reviews.llvm.org/D123698
Currently, lldb crashes when adding a stop hook with --shlib because we
unconditionally use the target in SymbolContextSpecifier::AddSpecification.
This patch prevents the crash and add a test.
rdar://68524781
Differential revision: https://reviews.llvm.org/D123746
Jim Ingham