Add DynamicRegisterInfo::registers() method that returns
llvm::iterator_range<> over RegisterInfos. This is a convenient
replacement for GetNumRegisters() + GetRegisterInfoAtIndex().
Differential Revision: https://reviews.llvm.org/D111136
Just regrouping the checks for the same typedef together and also giving the
different typedefs unique names. We might want to have a second test with
identical names to see how LLDB handle the potential name conflict, but that
should be a separate test and not part of the main typedef test.
Also this test is actually unintentionally passing. LLDB can't lookup typedefs
in a struct/class scope, but in the test the check passes as the local variable
in the expression evaluation scope pulls in the typedef. I added a second check
that makes it clear that this is not working right now.
ReadExtFeature provides equivalent functionality. Also fix a but in
ReadExtFeature, which prevented it from being used for auxv data (it
contains nul characters).
The previous version of the patch did not update the definitions in
conditionally compiled code. This patch includes changes to ARC and
windows targets.
Original commit message was:
These were added to support some mips registers on linux, but linux mips
support has now been removed due.
They are still referenced in the freebds mips implementation, but the
completeness of that implementation is also unknown. All other
architectures just set these fields to zero, which is a cause of
significant bloat in our register info definitions.
Arm also has registers with variable sizes, but they were implemented in
a more gdb-compatible fashion and don't use this feature.
Differential Revision: https://reviews.llvm.org/D110914
A Mach-O corefile has an array of memory segments, representing
the memory of the process at the point of the capture. Each segment
has a virtual address + size, and a file offset + size. The file
size may be less than the virtual address size, indicating that
the memory was unavailable. When ProcessMachCore::DoLoadCore scans
this array of memory segments, it builds up a table to translate
virtual addresses to file offsets, for memory read requests.
This lookup table combines contiguous memory segments into a single
entry, to reduce the number of entries (some corefile writers will
emit a separate segement for each virtual meory page).
This contiguous check wasn't taking into account a segment that
isn't present in the corefile, e.g. filesize==0, and every contiguous
memory segment after that point would result in lldb reading the
wrong offset of the file because it didn't account for this.
I'd like to have an error message when someone tries to read memory from
one of these segments, instead of returning all zeroes, so this patch
intentionally leaves these out of the vmaddr -> fileoff table (and
avoids combining them with segments that actually do exist in the
corefile).
I'm a little unsure of writing a test for this one; I'd have to do
a yaml2obj of a corefile with the problem, or add an internal mode
to the Mach-O process save-core where it could write a filesize==0
segment while it was writing one.
rdar://83382487
This reverts c7f16ab3e3 / r109694 - which
suggested this was done to improve consistency with the gdb test suite.
Possible that at the time GCC did not canonicalize integer types, and so
matching types was important for cross-compiler validity, or that it was
only a case of over-constrained test cases that printed out/tested the
exact names of integer types.
In any case neither issue seems to exist today based on my limited
testing - both gdb and lldb canonicalize integer types (in a way that
happens to match Clang's preferred naming, incidentally) and so never
print the original text name produced in the DWARF by GCC or Clang.
This canonicalization appears to be in `integer_types_same_name_p` for
GDB and in `TypeSystemClang::GetBasicTypeEnumeration` for lldb.
(I tested this with one translation unit defining 3 variables - `long`,
`long (*)()`, and `int (*)()`, and another translation unit that had
main, and a function that took `long (*)()` as a parameter - then
compiled them with mismatched compilers (either GCC+Clang, or
Clang+(Clang with this patch applied)) and no matter the combination,
despite the debug info for one CU naming the type "long int" and the
other naming it "long", both debuggers printed out the name as "long"
and were able to correctly perform overload resolution and pass the
`long int (*)()` variable to the `long (*)()` function parameter)
Did find one hiccup, identified by the lldb test suite - that CodeView
was relying on these names to map them to builtin types in that format.
So added some handling for that in LLVM. (these could be split out into
separate patches, but seems small enough to not warrant it - will do
that if there ends up needing any reverti/revisiting)
Differential Revision: https://reviews.llvm.org/D110455
This has the nice side-effect that it can actually store the quadruple version numbers that Apple's tools are using nowadays.
rdar://82982162
Differential Revision: https://reviews.llvm.org/D111200
Split the ABIX86 class into two classes: base ABIX86 class that is
common to 32-bit and 64-bit ABIs, and ABIX86_i386 class that is the base
for 32-bit ABIs. This removes the confusing concept that ABIX86
initializes 64-bit ABIs but is only the base for 32-bit ABIs.
Differential Revision: https://reviews.llvm.org/D111216
This reverts commit 00e704bf08.
This commit should should have updated
llvm/llvm-project/lldb/source/Plugins/ABI/ARC/ABISysV_arc.cpp like the other
architectures.
PT_COREDUMP is a relatively recent addition. Use an #ifdef to skip it
if the underlying system does not support it.
Differential Revision: https://reviews.llvm.org/D111214
Split the ABIX86 class into two classes: base ABIX86 class that is
common to 32-bit and 64-bit ABIs, and ABIX86_i386 class that is the base
for 32-bit ABIs. This removes the confusing concept that ABIX86
initializes 64-bit ABIs but is only the base for 32-bit ABIs.
Differential Revision: https://reviews.llvm.org/D111216
These were added to support some mips registers on linux, but linux mips
support has now been removed due.
They are still referenced in the freebds mips implementation, but the
completeness of that implementation is also unknown. All other
architectures just set these fields to zero, which is a cause of
significant bloat in our register info definitions.
Arm also has registers with variable sizes, but they were implemented in
a more gdb-compatible fashion and don't use this feature.
Differential Revision: https://reviews.llvm.org/D110914
This patch allows LLDB to accept register sizes which are not aligned
to 8 bits bitsize boundary. This fixes a crash in LLDB when connecting
to OpenOCD stub. GDB xml description allows for non-aligned bit lengths
but they are rounded off to nearest byte during transfer. In case of
OpenOCD some of SOC specific system registers were less than a single
byte in length and were causing LLDB to crash.
Reviewed By: labath
Differential Revision: https://reviews.llvm.org/D111131
JSON crashlogs normally start with a single line of meta data that we
strip unconditionally. Some producers started omitting the meta data
which tripped up crashlog. Be more resilient by only removing the first
line when we know it really is meta data.
rdar://82641662
Previously it was not clear what arguments this required, or what it would do if you didn't pass the destination argument.
Differential Revision: https://reviews.llvm.org/D110981
Move DynamicRegisterInfo from the internal lldbPluginProcessUtility
library to the public lldbTarget library. This is a prerequisite
towards ABI plugin changes that are going to pass DynamicRegisterInfo
parameters.
Differential Revision: https://reviews.llvm.org/D110942
This commit has introduced test failures in internal google tests.
Working theory is they are caused by a genuine problem in the patch
which gets tripped by some debug info from system libraries.
Reverting while we try to reproduce the problem in a self-contained
fashion.
This reverts commit 601168e420.
.. and reduce the scope of others. They don't follow llvm coding
standards (which say they should be used only when the same effect
cannot be achieved with the static keyword), and they set a bad example.
The `fallback` setting for import-std-module is supposed to allow running
expression that require an imported C++ module without causing any regressions
for users (neither in terms of functionality nor performance). This is done by
first trying to normally parse/evaluate an expression and when an error occurred
during this first attempt, we retry with the loaded 'std' module.
When we run into a system with a 'std' module that for some reason doesn't build
or otherwise causes parse errors, then this currently means that the second
parse attempt will overwrite the error diagnostics of the first parse attempt.
Given that the module build errors are outside of the scope of what the user can
influence, it makes more sense to show the errors from the first parse attempt
that are only concerned with the actual user input.
Reviewed By: aprantl
Differential Revision: https://reviews.llvm.org/D110696
The objc_clsopt_v16_t struct does not match up with the macOS/iOS15
dyld_shared_cache ObjC runtime structures. A struct field was seemingly
omitted.
Differential revision: https://reviews.llvm.org/D110477
Fix the termination of "process connect" (and "gdb-remote") to kill
the process rather than attempting to disconnect the platform.
The latter only results in an error since we did not use "platform
connect", and apparently process-level connections (at least via
gdb-remote) do not really support disconnecting.
Differential Revision: https://reviews.llvm.org/D110996
Separates the methods for recursive variable parsing in function
context and non-recursive parsing of global variables.
Differential Revision: https://reviews.llvm.org/D110570
We expose the fact that we rely on unsigned wrapping to iterate through
all indexes. This can be confusing. Rather, keeping it as an
implementation detail through an iterator is less confusing and is less
code.
Reviewed By: rnk
Differential Revision: https://reviews.llvm.org/D110885
Refactor TerminalState to make the code simpler. Move 'struct termios'
to a PImpl-style subclass. Add an RAII interface to automatically store
and restore the state.
Differential revision: https://reviews.llvm.org/D110721
The issue here was that we were not updating the interpreter's
execution context when calling HandleCommand to continue the process.
Since we had just created the process, it wasn't in the interpreter's
execution context so HandleCommand failed at CheckRequirements. The
patch fixes that by passing the process execution context directly
to HandleCommand.
Differential Revision: https://reviews.llvm.org/D110787
This change accomplishes the following:
- Moves `IRExecutionUnit::FindBestAlternateMangledName` to `Language`.
- Renames `FindBestAlternateMangledName` to
`FindBestAlternateFunctionMangledName`
- Changes the first parameter of said method from a `ConstString`
representing a demangled name to a `Mangled`.
- Remove the use of CPlusPlusLanguage from Expression
Usage of aux_size is guarded against elsewhere in this file, but is missing here.
Reviewed By: wallace
Differential Revision: https://reviews.llvm.org/D110269
Original Author: calebzulawski
Some downstream forks of LLDB change parts of the test setup in a way that
causes lldb to somehow resolve `std::abs` (probably to `::abs`). This patch
changes the tested function here to be `std::minmax` which (hopefully) doesn't
have any identically named functions that LLDB could find and call. Just to be
extra safe this also explicitly specified the template arguments so that in
case there is a `minmax` non-template function we still don't end up calling it
from this test.
Remove TerminalStateSwitcher class. It is not used anywhere and its API
is really weird. This is the first step towards cleaning up Terminal.h.
Differential Revision: https://reviews.llvm.org/D110693
Move the "slice" and "composite" handling into separate methods to avoid
if/else hell. Use more LLVM types whenever possible. Replace printf()s
with llvm::Error combined with LLDB logging.
Differential Revision: https://reviews.llvm.org/D110619
The two module retrieval methods (qXfer:libraries-svr4 and manual list
traversal) differ in how the handle the
manually-added-but-not-yet-loaded modules. The svr4 path will remove it,
while the manual one will keep in the list.
It's likely the two paths need ought to be synchronized, but right now,
this distinction is not relevant for the test.
We only had that ability for regular debugger launches. This meant that
it was not possible to use the normal dlopen patterns in attach tests.
This fixes that.
We added some support for this mode back in 2015, but the feature was
never productionized. It is completely untested, and there are known
major structural lldb issues that need to be resolved before this
feature can really be supported.
It also complicates making further changes to stop reply packet
handling, which is what I am about to do.
Differential Revision: https://reviews.llvm.org/D110553
Apparently macOS is padding the name result with several padding zeroes at
the end. Just strip them all to pretend it's a C-string.
Thanks to Pavel for suggesting this fix.
Add a convenience method to add supplementary registers that takes care
of adding invalidate_regs to all (potentially) overlapping registers.
Differential Revision: https://reviews.llvm.org/D110023
The StringConvert API is no longer used anywhere but in debugserver.
Since debugserver does not use LLVM API, we cannot replace it with
llvm::to_integer() and llvm::to_float() there. Let's just move
the sources into debugserver.
Differential Revision: https://reviews.llvm.org/D110478
Refactor the XML converting attribute and text getters to use LLVM API.
While at it, remove some redundant error and missing XML support
handling, as the called base functions do that anyway. Add tests
for these methods.
Note that this patch changes the getter behavior to be IMHO more
correct. In particular:
- negative and overflowing integers are now reported as failures to
convert, rather than being wrapped over or capped
- digits followed by text are now reported as failures to convert
to double, rather than their numeric part being converted
Differential Revision: https://reviews.llvm.org/D110410
When rebase_exec=true in DidAttach(), all modules are loaded
before the rendezvous breakpoint is set, which means the
LoadInterpreterModule() method is not called and m_interpreter_module
is not initialized.
This causes the very first rendezvous breakpoint hit with
m_initial_modules_added=false to accidentally unload the
module_sp that corresponds to the dynamic loader.
This bug (introduced in D92187) was causing the rendezvous
mechanism to not work in Android 28. The mechanism works
fine on older/newer versions of Android.
Test: Verified rendezvous on Android 28 and 29
Test: Added dlopen test
Reviewed By: labath
Differential Revision: https://reviews.llvm.org/D109797
Add a llvm::Split() implementation that can be used via range-for loop,
e.g.:
for (StringRef x : llvm::Split("foo,bar,baz", ','))
...
The implementation uses an additional SplittingIterator class that
uses StringRef::split() internally.
Differential Revision: https://reviews.llvm.org/D110496
Replace the uses of StringConvert combined with hand-rolled array
splitting with llvm::StringRef.split() and llvm::to_integer().
Differential Revision: https://reviews.llvm.org/D110472
Replace misc. StringConvert uses with llvm::to_integer()
and llvm::to_float(), except for cases where further refactoring is
planned. The purpose of this change is to eliminate the StringConvert
API that is duplicate to LLVM, and less correct in behavior at the same
time.
Differential Revision: https://reviews.llvm.org/D110447
Linking against the LibXml2::LibXml2 target has the advantage of not only importing the library, but also adding the include path as well as any definitions the library requires. In case of a static build of libxml2, eg. a define is set on Windows to remove any DLL imports and export.
LLVM already makes use of the target, but c-index-test and lldb were still linking against the library only.
The workaround for Mac OS-X that I removed seems to have also been made redundant since https://reviews.llvm.org/D84563 I believe
Differential Revision: https://reviews.llvm.org/D109975
When using the system debugserver for testing, copy the binary in the
LLDB.framework Resource directory instead of the build's bin directory.
rdar://82998263
Refactor Socket::DecodeHostAndPort() to use LLVM API over redundant
LLDB API. In particular, this means llvm::Regex, llvm::Error return
type and llvm::to_integer().
While at it, change the port type from int32_t to uint16_t. The method
never returns any value outside this range, and using the correct type
allows us to rely on getAsInteger()'s implicit overflow check.
Differential Revision: https://reviews.llvm.org/D110391
Refactor Socket::DecodeHostAndPort() to use LLVM API over redundant
LLDB API. In particular, this means llvm::Regex, llvm::Error return
type and llvm::to_integer().
While at it, change the port type from int32_t to uint16_t. The method
never returns any value outside this range, and using the correct type
allows us to rely on getAsInteger()'s implicit overflow check.
Differential Revision: https://reviews.llvm.org/D110391
If the remote gdbserver's qfThreadInfo reply has a trailing comma,
GDBRemoteCommunicationClient::GetCurrentProcessAndThreadIDs will return
an empty vector of thread ids. This will cause lldb to recurse through
three functions trying to get the list of threads, until it blows its
stack and crashes.
A trailing comma is a malformed response, but it shouldn't cause lldb to
crash. This patch will return the tids received before the malformed
response.
Reviewed By: clayborg, labath
Differential Revision: https://reviews.llvm.org/D109937
If we applied a fix-it before evaluating an expression and that
expression didn't evaluate correctly, we should still tell users about
the fix-it we applied since that may be the reason why it didn't work
correctly.
Differential Revision: https://reviews.llvm.org/D109908
Switch the gdb-remote client logic to use local (LLDB) register numbers
in value_regs/invalidate_regs rather than remote regnos. This involves
translating regnos received from lldb-server.
Differential Revision: https://reviews.llvm.org/D110027
Refactor remote register getters to collect them into a local
std::vector rather than adding them straight into DynamicRegisterInfo.
The purpose of this change is to lay groundwork for switching value_regs
and invalidate_regs to use local LLDB register numbers rather than
remote numbers.
Differential Revision: https://reviews.llvm.org/D110025
LLDB has a bunch of code that implements REPL support, but all that code is
unreachable as no language in master currently has an implemented REPL backend.
The only REPL that exists is in the downstream Swift fork. All patches for this
generic REPL code therefore also only have tests downstream which is clearly not
a good situation.
This patch implements a basic C language REPL on top of LLDB's REPL framework.
Beside implementing the REPL interface and hooking it up into the plugin
manager, the only other small part of this patch is making the `--language` flag
of the expression command compatible with the `--repl` flag. The `--repl` flag
uses the value of `--language` to see which REPL should be started, but right
now the `--language` flag is only available in OptionGroups 1 and 2, but not in
OptionGroup 3 where the `--repl` flag is declared.
The REPL currently can currently only start if a running target exists. I'll add
the 'create and run a dummy executable' logic from Swift (which is requires when
doing `lldb --repl`) when I have time to translate all this logic to something
that will work with Clang.
I should point out that the REPL currently uses the C expression parser's
approach to persistent variables where only result variables and the ones
starting with a '$' are transferred between expressions. I'll fix that in a
follow up patch. Also the REPL currently doesn't work in a non-interactive
terminal. This seems to be fixed in the Swift fork, so I assume one of our many
REPL downstream changes addresses the issue.
Reviewed By: JDevlieghere
Differential Revision: https://reviews.llvm.org/D87281
Switch the gdb-remote client logic to use local (LLDB) register numbers
in value_regs/invalidate_regs rather than remote regnos. This involves
translating regnos received from lldb-server.
Differential Revision: https://reviews.llvm.org/D110027
Refactor remote register getters to collect them into a local
std::vector rather than adding them straight into DynamicRegisterInfo.
The purpose of this change is to lay groundwork for switching value_regs
and invalidate_regs to use local LLDB register numbers rather than
remote numbers.
Differential Revision: https://reviews.llvm.org/D110025
getpeername will return addrlen = 2 (sizeof sa_family_t) for unnamed
sockets (those not assigned a name with bind(2)). This is typically true
for client sockets as well as those created by socketpair(2).
This GetSocketName used to crash for sockets which were connected to
these kinds of sockets. Now it returns an empty string.
The work that IRExecutionUnit::CollectFallbackNames is basically the
work that `CPlusPlusLanguage::GetDemangledFunctionNameWithoutArguments`
does already. It's also (at time or writing) specific to C++, so it can
be folded into `IRExecutionUnit::CollectCandidateCPlusPlusNames`.
Differential Revision: https://reviews.llvm.org/D109928
At first, lli only supported lazy mode for ORC. Greedy mode was added with e1579894d2 and is the default settings now. JITLoaderGDB tests don't rely on laziness, so we can switch them to greedy and remove some complexity.
Currently you can ask the target symbols add command to locate the debug
symbols for the current frame. This patch add an options to do that for
the whole call stack.
Differential revision: https://reviews.llvm.org/D110011
Trying to use the DIA SDK reader only to fail with "DIA SDK wasn't enabled"
isn't very useful. The native PDB reader is missing some stuff, but it's still
better than nothing.
Reduces number of lldb-check-shell test failures with LLVM_ENABLE_DIA_SDK=NO
from 27 to 15.
Differential Revision: https://reviews.llvm.org/D110172
This test relies on being able to unwind from an arbitrary place inside
libc. While I am not sure this is the cause of the observed flakyness,
it is known that we are not able to unwind correctly from some places in
(linux) libc.
This patch adds additional synchronization to ensure that the inferior
is in the main function (instead of pthread guts) when lldb tries to
unwind it. At the very least, it should make the test runs more
predictable/repeatable.
When adding an image to a target for crashlog purposes, avoid specifying
the architecture of the image.
This has the effect of making SBTarget::AddModule infer the ArchSpec for
the image based on the SBTarget's architecture, which LLDB puts serious
effort into calculating correctly (in TargetList::CreateTargetInternal).
The status quo is that LLDB randomly guesses the ArchSpec for a module
if its architecture is specified, via:
```
SBTarget::AddModule -> Platform::GetAugmentedArchSpec -> Platform::IsCompatibleArchitecture ->
GetSupportedArchitectureAtIndex -> {ARM,x86}GetSupportedArchitectureAtIndex
```
... which means that the same crashlog can fail to load on an Apple
Silicon Mac (due to the random guess of arm64e-apple-macosx for the
module's ArchSpec not being compatible with the SBTarget's (correct)
ArchSpec), while loading just fine on an Intel Mac.
I'm not sure how to add a test for this (it doesn't look like there's
test coverage of this path in-tree). It seems like it would be pretty
complicated to regression test: the host LLDB would need to be built for
arm64e, we'd need a hand-crafted arm64e iOS crashlog, and we'd need a
binary with an iOS deployment target. I'm open to other / simpler
options.
rdar://82679400
Differential Revision: https://reviews.llvm.org/D110013
This moves the logic for adding symbols based on UUID, file and frame
into little helper functions. This is in preparation for D110011.
Differential revision: https://reviews.llvm.org/D110010
Set value_regs and invalidate_regs in RegisterInfo pushed onto m_regs
to nullptr, to ensure that the temporaries passed there are not
accidentally used.
Differential Revision: https://reviews.llvm.org/D109879
Always send PID in the detach packet when multiprocess extensions are
enabled. This is required by qemu's GDB server, as plain 'D' packet
results in an error and the emulated system is not resumed.
Differential Revision: https://reviews.llvm.org/D110033
These have been here since r215992, guarding the calls to HostInfo, but
their purpose unclear -- HostInfoLinux provides these functions and they
work fine.
A MachO userspace corefile may contain LC_THREAD commands which specify
thread exception state.
For arm64* only (for now), report a human-readable version of this state
as the thread stop reason, instead of 'SIGSTOP'.
As a follow-up, similar functionality can be implemented for x86 cores
by translating the trapno/err exception registers.
rdar://82898146
Differential Revision: https://reviews.llvm.org/D109795
This reverts commit 47dd1f6428.
After discussing with Jim Ingham, we agreed to leave the test as-is
so we can catch any CI problems instead of silently skipping the test.
A MachO userspace corefile may contain LC_THREAD commands which specify
thread exception state.
For arm64* only (for now), report a human-readable version of this state
as the thread stop reason, instead of 'SIGSTOP'.
As a follow-up, similar functionality can be implemented for x86 cores
by translating the trapno/err exception registers.
rdar://82898146
Differential Revision: https://reviews.llvm.org/D109795
I have 2 goals with this change:
1. Disambiguate between CPlusPlus::FindAlternateFunctionManglings and
IRExecutionUnit::FindBestAlternateMangledName. These are named very
similar things, they try to do very similar things, but their
approaches are different. This change should make it clear that one
is generating possible alternate manglings (through some
heuristics-based approach) and the other is finding alternate
manglings (through searching the SymbolFile for potential matches).
2. Change GenerateAlternateFunctionManglings from a static method in
CPlusPlusLanguage to a virtual method in Language. This will allow us
to remove a direct use of CPlusPlusLanguage in IRExecutionUnit,
further pushing it to be more general. This change doesn't meet this
goal completely but allows for it to happen later.
Though this doesn't remove IRExecutionUnit's dependency on
CPlusPlusLanguage, it does bring us closer to that goal.
Differential Revision: https://reviews.llvm.org/D109785
xcodebuild, which is invoked by the apple_simulator_test decorator, may
may return a successful status even if it was unable to run due to the
authorization agent denying it. This causes the TestAppleSimulatorOSType
to run when it shouldn't, and throw an excpection when parsing the JSON
that lists the simulators available. Wrap the json parsing in a
try/except block and if it fails, skip the ttest.
Differential Revision: https://reviews.llvm.org/D109336
This way, we do not need to set LLVM_CMAKE_PATH to LLVM_CMAKE_DIR when (NOT LLVM_CONFIG_FOUND)
Reviewed By: #libc, ldionne
Differential Revision: https://reviews.llvm.org/D107717
lit.util.which('link') picks up the wrong link.exe in git bash, leading
to this error:
# command stderr:
/usr/bin/link: extra operand '/LIBPATH:C:\\Progra....'
Try '/usr/bin/link --help' for more information.
Instead, assume that link.exe is next to cl.exe.
Differential Revision: https://reviews.llvm.org/D109832
Alias the "sp" register to "x31" on AArch64 if one is present and does
not have the alt_name. This is the case when connecting to gdbserver.
Differential Revision: https://reviews.llvm.org/D109695
Remove the name and alt_name parameters from AddRegister() and instead
pass them via RegisterInfo.name and .alt_name fields. This makes
the API simpler and removes some duplication.
Differential Revision: https://reviews.llvm.org/D109872
instead of a pointer. There are just two callers of this function, and
both of them have a valid target pointer, so there's no need for all
implementations to concern themselves with whether the pointer is null.
When the corefile reader is adding binaries from the "all image
infos" LC_NOTE in a Mach-O corefile, it would detect if the binary
being added was an executable binary and set it as the Target's
executable binary. This has the side effect of clearing the Target's
image list, so if the executable was in the middle of the all image
infos, the initial images would be dropped. There's no need to set
the executable binary in the Target for these corefile processes,
so instead of doing multiple passes over the list to find the
executable, I'm dropping that.
Recognize lr/sp/fp by their numeric register names in the ABI plugin.
This is necessary to mark them appropriately when interfacing with
gdbserver.
Differential Revision: https://reviews.llvm.org/D109691
Try determining the process architecture from <architecture/> tag
unconditionally, rather than for very specific cases. Generic gdbserver
implementations do not support LLDB-specific packets used to determine
the process architecture, therefore this fallback is necessary to
support architecture-specific behavior on these targets. Rather than
maintaining a mapping of all known architectures, just try mapping
the GDB values into triplets, as that is going to work most of the time.
This change is confirmed to fix LLDB against gdbserver when debugging
i386 and aarch64 executables.
Differential Revision: https://reviews.llvm.org/D109272
The thread that Visual Studio Code displays on a stop is called the focus thread. When the previous focus thread exits and we stop in a new thread, lldb-vscode does not tell vscode to set the new thread as the focus thread, so it selects the first thread in the thread list.
This patch changes lldb-vscode to tell vscode that the new thread is the focus thread. It also includes a test that verifies the DAP stop message for this case contains the correct values.
Reviewed By: clayborg, wallace
Differential Revision: https://reviews.llvm.org/D109633
This addresses the flakyness of (at least) TestMultilineNavigation,
which was failing when the editline history of a concurrently executing
test made leaked in. Using a test-specific home directory ensures the
tests are independent.
Fixes the following warning:
$llvm_project/lldb/source/Plugins/ObjectFile/Minidump/MinidumpFileBuilder.cpp:744:11: warning:
format specifies type 'long' but the argument has type 'lldb::offset_t' (aka 'unsigned long long') [-Wformat]
m_data.GetByteSize());
^~~~~~~~~~~~~~~~~~~~
Remove the parent output checks, as they make the test flaky while
serving no real purpose. If the parent crashed/hanged, it will never
resume the child and the test would fail anyway.
Remove redundant register alt_names that correspond to their respective
generic names. D108554 makes it possible to query registers through
their generic names directly, therefore making repeating them via
alt_name unnecessary.
While at it, also remove alt_names that are equal to register names
on PPC.
This patch does not alter register definitions where the generic names
are listed as primary names, and other names are provided as alt_name
(e.g. ARM).
Differential Revision: https://reviews.llvm.org/D109626
Update GetRegisterInfoByName() methods to support getting registers
by a generic name independently of alt_name entries in the register
context. This makes it possible to use generic names when interacting
with gdbserver (that does not supply alt_names). It also makes it
possible to remove some of the duplicated information from register
context declarations and/or use alt_names for another purpose.
Differential Revision: https://reviews.llvm.org/D108554
In all these years, we haven't found a use for this function (it has
zero callers). Lets just remove the boilerplate.
Differential Revision: https://reviews.llvm.org/D109600
Regex is matching a binary so it needs `re.DOTALL`.
vFile:fstat packet data ATTACHMENT is not hex-encoded but it is only
escaped.
It is difficult to reproduce, it came from buildbot:
https://lab.llvm.org/staging/#/builders/16/builds/10597
******************** TEST 'lldb-api :: tools/lldb-server/TestGdbRemotePlatformFile.py' FAILED ********************
FAIL: test_platform_file_fstat_llgs (TestGdbRemotePlatformFile.TestGdbRemotePlatformFile)
----------------------------------------------------------------------
Traceback (most recent call last):
File "lldb/packages/Python/lldbsuite/test/tools/lldb-server/gdbremote_testcase.py", line 52, in test_method
return attrvalue(self)
File "lldb/test/API/tools/lldb-server/TestGdbRemotePlatformFile.py", line 259, in test_platform_file_fstat
context = self.expect_gdbremote_sequence()
File "lldb/packages/Python/lldbsuite/test/tools/lldb-server/gdbremote_testcase.py", line 621, in expect_gdbremote_sequence
return expect_lldb_gdbserver_replay(
File "lldb/packages/Python/lldbsuite/test/tools/lldb-server/lldbgdbserverutils.py", line 198, in expect_lldb_gdbserver_replay
context = sequence_entry.assert_match(
File "lldb/packages/Python/lldbsuite/test/tools/lldb-server/lldbgdbserverutils.py", line 479, in assert_match
return self._assert_regex_match(asserter, actual_packet, context)
File "lldb/packages/Python/lldbsuite/test/tools/lldb-server/lldbgdbserverutils.py", line 446, in _assert_regex_match
asserter.fail(
AssertionError: regex '^\$F([0-9a-fA-F]+);(.*)#[0-9a-fA-F]{2}$' failed to match against content '$F40;^@^@^@ ^@
^C<8d>^@^@<81><80>^@^@^@^A^@^@^CX^@^@^CX^@^@^@^@^@^@^@^@^@^@^@^W^@^@^@^@^@^@^P^@^@^@^@^@^@^@^@
a=XXa=XXa=XX#6b'
TestDyldLaunchLinux.py has been recently added and is failing on LLDB
Arm/Linux buildbot. I am marking it skip till I come back and look at
it in more detail.
In macOS 12, the symbol name for the dyld_all_image_infos struct
in dyld has a namespace qualifier. Search for it without qualification,
then with qualification when doing a by-name search. (lldb will
only search for it by name when loading a user process Mach-O corefile)
rdar://76270013
GDB uses normalized errno values for vFile errors. Implement
the translation between them and system errno values in the gdb-remote
plugin.
Differential Revision: https://reviews.llvm.org/D108148
Fall back to QEnvironmentHexEncoded if QEnvironment is not supported.
The latter packet is an LLDB extension, while the former is universally
supported.
Add tests for both QEnvironment and QEnvironmentHexEncoded packets,
including both use due to characters that need escaping and fallback
when QEnvironment is not supported.
Differential Revision: https://reviews.llvm.org/D108018
Implement the simpler vRun packet and prefer it over the A packet.
Unlike the latter, it tranmits command-line arguments without redundant
indices and lengths. This also improves GDB compatibility since modern
versions of gdbserver do not implement the A packet at all.
Make qLaunchSuccess not obligatory when using vRun. It is not
implemented by gdbserver, and since vRun returns the stop reason,
we can assume it to be successful.
Differential Revision: https://reviews.llvm.org/D107931
Add a GDB-compatible fallback to vFile:fstat for vFile:mode, and to
vFile:open for vFile:exists. Note that this is only partial fallback,
as it fails if the file cannot be opened.
Differential Revision: https://reviews.llvm.org/D107811
Add two new commands 'platform get-file-permissions' and 'platform
file-exists' for the respective bits of LLDB protocol. Add tests for
them. Fix error handling in GetFilePermissions().
Differential Revision: https://reviews.llvm.org/D107809
Create a common GDBPlatformClientTestBase class and move the platform
select/connect logic there to reduce duplication.
Differential Revision: https://reviews.llvm.org/D109585
D101329 introduces the Process:SaveCore function returning a
`llvm::Expected<bool>`. That function causes that Clang with -fmodules crashes
while compiling LLDB's PythonDataObjects.cpp. With enabled asserts Clang fails
because of:
Assertion failed: (CachedFieldIndex && "failed to find field in parent")
Crash can be reproduced by building via -DLLVM_ENABLE_MODULES=On with Clang
12.0.1 and then building PythonDataObjects.cpp.o .
Clang bug is tracked at rdar://82901462
We set breakpoint on child_func, so synchronization inside it is too
late to guarantee ordering between the parent output and child
breakpoint. Split the function in two, and perform synchronization
before the breakpoint.
Differential Revision: https://reviews.llvm.org/D109591
Implement a fallback to getting the file size via vFile:stat packet
when the remote server does not implement vFile:size. This makes it
possible to query file sizes from remote gdbserver.
Note that unlike vFile:size, the fallback will not work if the server is
unable to open the file.
While at it, add a few tests for the 'platform get-size' command.
Differential Revision: https://reviews.llvm.org/D107780
Add synchronization routines to ensure that Subprocess tests output
in a predictable order, and all test strings are output before the tests
terminate.
Differential Revision: https://reviews.llvm.org/D109495
Report timeout exceeded and connection lost error messages
when sending the initial handshake packet in a gdb remote
serial protocol connection, an especially fragile time.
Differential Revision: https://reviews.llvm.org/D108888
This renames the primary methods for creating a zero value to `getZero`
instead of `getNullValue` and renames predicates like `isAllOnesValue`
to simply `isAllOnes`. This achieves two things:
1) This starts standardizing predicates across the LLVM codebase,
following (in this case) ConstantInt. The word "Value" doesn't
convey anything of merit, and is missing in some of the other things.
2) Calling an integer "null" doesn't make any sense. The original sin
here is mine and I've regretted it for years. This moves us to calling
it "zero" instead, which is correct!
APInt is widely used and I don't think anyone is keen to take massive source
breakage on anything so core, at least not all in one go. As such, this
doesn't actually delete any entrypoints, it "soft deprecates" them with a
comment.
Included in this patch are changes to a bunch of the codebase, but there are
more. We should normalize SelectionDAG and other APIs as well, which would
make the API change more mechanical.
Differential Revision: https://reviews.llvm.org/D109483
This feature doesn't seem to have any dedicated test. Instead some random tests
(e.g. the bitfield tests) are declaring function-local classes for some reason.
This adds a dedicated test so we can clean up those other tests.
Also add FIXME's for some basic stuff that doesn't work. The first FIXME is a
good beginner bug which just requires prepending the function name (in case we
decide to fix it instead of documenting this behaviour). The second FIXME is
caused by LLDB searching for definitions by name (which also seems to miss the
function name so there is a conflict with the outer type).
Some more things that should be tested (and might not work):
* Local classes with member functions with local classes.
* Classes in different functions with same name.
* Classes with the same name in different TUs with internal linkage functions of
the same name.
* Empty classes are parsed by the DWARF parser in a fast path, so that requires
dedicated tests.
* Repeat some of the tested logic for C.
This patch fixes register save/restore on expression call to also include SVE registers.
This will fix expression calls like:
re re p1
<Register Value P1 before expression>
p <var-name or function call>
re re p1
<Register Value P1 after expression>
In above example register P1 should remain the same before and after the expression evaluation.
Reviewed By: DavidSpickett
Differential Revision: https://reviews.llvm.org/D108739
IRExecutionUnit::SearchSpec is a struct that encapsulates information
needed to look for a symbol. Specifically, it is comprised of a name
represented with a ConstString and a FunctionNameType mask.
Because the mask is unused (effectively always set to
eFunctionNameTypeFull), we can remove the mask and replace all uses with
eFunctionNameTypeFull. After doing that, SearchSpec is effectively a
wrapper around a ConstString.
As an aside, SearchSpec is similar in purpose to Module::LookupInfo. I
briefly considered replacing uses of SearchSpec with LookupInfo, but
the current code only cares about symbol names (treating them as
eFunctionNameTypeFull). This code does care about language type, so
LookupInfo may be appropriate for IRExecutionUnit in the future.
Differential Revision: https://reviews.llvm.org/D109384
Remove File::eOpenOptionAppend from the mode used by 'platform file
open' command. According to POSIX, O_APPEND causes all successive
writes to be done at the end of the file. This effectively makes
the offset argument to 'platform file write' meaningless.
Furthermore, apparently O_APPEND is not implemented reliably everywhere.
The Linux manpage for pwrite(2) suggests that Linux does respect
O_APPEND there while according to POSIX it should not, so the actual
behavior would be dependent on how the vFile:pwrite packet is
implemented on the server.
Ideally, the mode used for opening flags would be provided via options.
However, changing the default mode seems to be a reasonable intermediate
solution.
Differential Revision: https://reviews.llvm.org/D107664
Enhance the generic register fallback code to support "eflags" register
name in addition to "rflags", as the former is used by gdbserver. This
permits lldb-server to recognize the generic flags register when
interfacing with gdbserver-style target.xml (i.e. without generic=""
attributes), and therefore aligns ABI plugins' AugmentRegisterInfo()
between lldb-server and gdbserver.
Differential Revision: https://reviews.llvm.org/D108548
Fix 'platform file read' and 'platform file write' commands to correctly
detect erraneous return and report it as such. Currently, errors were
implicitly printed as a return value of -1, and the commands were
assumed to be successful.
Differential Revision: https://reviews.llvm.org/D107665
This is enough to get the lit-based tests to pass on macOS.
Doesn't yet add build targets for:
- Any LLDB unit tests
- swig bindings
- various targets not needed by lit tests
LLDB has many dependency cycles, something GN doesn't allow. For
that reason, I've omitted some dependency edges. Hopefully we can
clean up the cycles one day.
LLDB has a public/private header distinction, but mostly ignores it.
Many libraries include private headers from other modules.
Since LLDB is the first target the LLVM/GN build that uses Objective-C++
code, add some machinery to the toolchain file to handle that.
Differential Revision: https://reviews.llvm.org/D109185
mdfind can return multiple results, some of which are not even dSYM
bundles, but Xcode archives (.xcrachive).
Currently, we end up concatenating the paths, which is obviously bogus.
This patch not only fixes that, but now also skips paths that don't have
a Contents/Resources/DWARF subdirectory.
rdar://81270312
Differential revision: https://reviews.llvm.org/D109263
Extend PluginManager::SaveCore() to support saving core dumps
via Process plugins. Implement the client-side part of qSaveCore
request in the gdb-remote plugin, that creates the core dump
on the remote host and then uses vFile packets to transfer it.
Differential Revision: https://reviews.llvm.org/D101329
lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.cpp:4765:13: warning: enumeration value 'Ibm128' not handled in switch [-Wswitch]
switch (llvm::cast<clang::BuiltinType>(qual_type)->getKind()) {
^
Add a new SaveCore() process method that can be used to request a core
dump. This is currently implemented on NetBSD via the PT_DUMPCORE
ptrace(2) request, and enabled via 'savecore' extension.
Protocol-wise, a new qSaveCore packet is introduced. It accepts zero
or more semicolon-separated key:value options, invokes the core dump
and returns a key:value response. Currently the only option supported
is "path-hint", and the return value contains the "path" actually used.
The support for the feature is exposed via qSaveCore qSupported feature.
Differential Revision: https://reviews.llvm.org/D101285
This patch should fix the build failure that surfaced when build llvm
with GCC: https://lab.llvm.org/staging/#/builders/16/builds/10450
GCC complained that I explicitely specialized
`ScriptedPythonInterface::ExtractValueFromPythonObject` in a
in non-namespace scope, which is tolerated by Clang.
To solve this issue, the specialization were declared out of the class
and implemented in the source file.
Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
This patch splits the previous `ScriptedProcessPythonInterface` into
multiple specific classes:
1. The `ScriptedInterface` abstract class that carries the interface
instance object and its virtual pure abstract creation method.
2. The `ScriptedPythonInterface` that holds a generic `Dispatch` method that
can be used by various interfaces to call python methods and also keeps a
reference to the Python Script Interpreter instance.
3. The `ScriptedProcessInterface` that describes the base Scripted
Process model with all the methods used in the underlying script.
All these components are used to refactor the `ScriptedProcessPythonInterface`
class, making it more modular.
This patch is also a requirement for the upcoming work on `ScriptedThread`.
Differential Revision: https://reviews.llvm.org/D107521
Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
This patch considers the CU index entry
when reading the .debug_rnglists.dwo section.
Reviewed By: jankratochvil
Differential Revision: https://reviews.llvm.org/D107456
Due to CMake cache, find_package in FindLuaAndSwig.cmake
will be ignored. This commit adds EXACT and REQUIRED flags
to it and removes find_package in Lua ScriptInterpreter.
Signed-off-by: Siger Yang <sigeryeung@gmail.com>
Reviewed By: tammela, JDevlieghere
Differential Revision: https://reviews.llvm.org/D108515
Implement a new target.process.follow-fork-mode setting to control
LLDB's behavior on fork. If set to 'parent', the forked child is
detached and parent continues being traced. If set to 'child',
the parent is detached and child becomes traced instead.
Differential Revision: https://reviews.llvm.org/D100503
This diff modifies the LLDB server return codes to more accurately reflect usage
error paths. Specifically we always propagate the return codes from the main
entrypoints into GDB remote LLDB server, and platform LLDB server. This way, the
top-level caller of LLDB server will be able to correctly check whether the
executable exited with or without an error.
We additionally modify and extend the associated shell unit tests to expect
nonzero return codes on error conditions.
Test Plan:
LLDB tests pass:
```
ninja check-lldb
```
Reviewed By: teemperor
Differential Revision: https://reviews.llvm.org/D108351
This change adds save-core functionality into the ObjectFileELF that enables
saving minidump of a stopped process. This change is mainly targeting Linux
running on x86_64 machines. Minidump should contain basic information needed
to examine state of threads, local variables and stack traces. Full support
for other platforms is not so far implemented. API tests are using LLDB's
MinidumpParser.
This relands commit aafa05e, reverted in 1f986f6.
Failed tests were fixed.
Reviewed By: clayborg
Differential Revision: https://reviews.llvm.org/D108233
Temporarily remove breakpoints for the duration of vfork, in order
to prevent them from triggering in the child process. Restore them
once the server reports that vfork has finished and it is ready to
resume execution.
Differential Revision: https://reviews.llvm.org/D100267
Temporarily remove breakpoints for the duration of vfork, in order
to prevent them from triggering in the child process. Restore them
once the server reports that vfork has finished and it is ready to
resume execution.
Differential Revision: https://reviews.llvm.org/D100267
It is easy to accidentally introduce a deadlock by having the callback
passed to Language::ForEach also attempt to acquire the same lock. It
is easy enough to disallow the callback from calling anything in
Language directly, but it may happen through a series of other
function/method calls.
The solution I am proposing is to tighten the lock in Language::ForEach
so that it is only held as we gather the currently loaded language
plugins. We store them in a vector and then iterate through them with
the callback so that the callback can't introduce a deadlock.
Differential Revision: https://reviews.llvm.org/D109013
Right now running `expr` to start the multiline expression editor and then
pressing enter causes an empty history empty to be created for the multiline
editor. That doesn't seem very useful for users as pressing the 'up' key will
now also bring up these empty expressions.
I don't think there is ever a use case for recalling a completely empty
expression from the history, so instead don't save those entries to the history
file and make sure we never recall them when navigating over the expression
history.
Note: This is actually a Swift downstream patch that got shipped with Apple's
LLDB for many years. However, this recently started conflicting with upstream
LLDB as D100048 added a test that made sure that empty expression entries don't
crash LLDB. Apple's LLDB was never affected by this crash as it never saved
empty expressions in the first place.
Reviewed By: augusto2112
Differential Revision: https://reviews.llvm.org/D108983
Remove software breakpoints from forked processes in order to restore
the original program code before detaching it.
Differential Revision: https://reviews.llvm.org/D100263
This change adds save-core functionality into the ObjectFileELF that enables
saving minidump of a stopped process. This change is mainly targeting Linux
running on x86_64 machines. Minidump should contain basic information needed
to examine state of threads, local variables and stack traces. Full support
for other platforms is not so far implemented. API tests are using LLDB's
MinidumpParser.
Reviewed By: clayborg
Differential Revision: https://reviews.llvm.org/D108233
When adding a dSYM to a Module and it has different file addresses
from the already-present ObjectFile binary, change the Sections to
use the dSYM's file addresses so the symbol table and DWARF are
properly contained in the Sections. Previously this was only done
for IsInMemory ObjectFiles, but it's more common than that.
Differential Revision: https://reviews.llvm.org/D108889
rdar://81504400
This file contain some old reference to files those are now either renamed or replaced.
Also this .txt file didn't generate to html during the sphnix documentation build so I send its contents to resources/test.rst file.
Signed-off-by: Shivam Gupta <shivam98.tkg@gmail.com>
Reviewed By: teemperor, mgorny, JDevlieghere
Differential Revision: https://reviews.llvm.org/D108812
Upadate some .txt files to .rst for consistency as most
of the documentation is written in reStructuredText format.
Signed-off-by: Shivam Gupta <shivam98.tkg@gmail.com>
Differential Revision: https://reviews.llvm.org/D108807
When I run a lldb command that uses filename completion, if I enter a string
that is not only a filename but also a string with a non-file name string added,
such as "./" that is relative path string , it will crash as soon as I press the
[Tab] key. For example, debugging an executable file named "hello" that is
compiled from a file named "hello.c" , and I’ll put a breakpoint on line 3 of
hello.c.
```
$ lldb ./hello
(lldb) breakpoint set --file hello.c --line 3
```
This is not a problem, but if I set "--file ./hello." and then press [Tab] key
to complete file name, lldb crashes.
```
$ lldb ./hello
(lldb) breakpoint set --file ./hello.terminate called after throwing an instance of 'std::out_of_range'
what(): basic_string::substr: __pos (which is 8) > this->size() (which is 7)
```
The crash was caused because substr() (in lldb/source/Host/common/Editline.cpp)
cut out string which size is user's input string from the completion string.
I modified the code that erase the user's intput string from current line and
then add the completion string.
Differential Revision: https://reviews.llvm.org/D108817
Previously, if no column was specified, ResolveSymbolContext would take
the first match returned by FindLineEntryIndexByFileIndex, and reuse it
to find subsequent exact matches. With the introduction of columns, columns
are now considered when matching the line entries.
This leads to a problem if one wants to get all existing line entries
that match that line, since now the column is also used for the exact match.
This way, all line entries are filtered out that have a different
column number, but the same line number.
This patch changes that by ignoring the column information of the first match
if the original request of ResolveSymbolContext was also ignoring it.
Reviewed By: mib
Differential Revision: https://reviews.llvm.org/D108816
Add a support for handling fork/vfork stops in LLGS client. At this
point, it only sends a detach packet for the newly forked child
(and implicitly resumes the parent).
Differential Revision: https://reviews.llvm.org/D100206
It is currently possible to register a frame recognizer, but it will be applied if and only if the frame's PC points to the very first instruction of the specified function, which limits usability of this feature.
The implementation already supports changing this behaviour by passing an additional flag, but it's not possible to set it via the command interface. Fix that.
Reviewed By: jingham
Differential Revision: https://reviews.llvm.org/D108510
added new command "process trace save -d <directory>".
-it saves a JSON file as <directory>/trace.json, with the main properties of the trace session.
-it saves binary Intel-pt trace as <directory>/thread_id.trace; each file saves each thread.
-it saves modules to the directory <directory>/modules .
-it only works for live process and it only support Intel-pt right now.
Example:
```
b main
run
process trace start
n
process trace save -d /tmp/mytrace
```
A file named trace.json and xxx.trace should be generated in /tmp/mytrace. To load the trace that was just saved:
```
trace load /tmp/mytrace
thread trace dump instructions
```
You should see the instructions of the trace got printed.
To run a test:
```
cd ~/llvm-sand/build/Release/fbcode-x86_64/toolchain
ninja lldb-dotest
./bin/lldb-dotest -p TestTraceSave
```
Reviewed By: wallace
Differential Revision: https://reviews.llvm.org/D107669
I was debugging a problem and noticed that it would have been helpful to have
the type of each FieldDecl when looking at the output from
ClangASTSource::layoutRecordType.
Differential Revision: https://reviews.llvm.org/D108257
This patch adds a new type of reusable UI components. Searcher Windows
contain a text field to enter a search keyword and a list of scrollable
matches are presented. The target match can be selected and executed
which invokes a user callback to do something with the match.
This patch also adds one searcher delegate, which wraps the common
command completion searchers for simple use cases.
Reviewed By: clayborg
Differential Revision: https://reviews.llvm.org/D108545
This patch removed some typos from NativeRegisterContextLinux_arm and
NativeRegisterContextLinux_arm64. Some of the log/error messages were
being reported as x86_64.
Module::LookupInfo's constructor currently goes over supported languages
trying to figure out the best way to search for a symbol name. This
seems like a great candidate for refactoring. Specifically, this is work
that can be delegated to language plugins.
Once again, the goal here is to further decouple plugins from
non-plugins. The idea is to have each language plugin take a name and
give you back some information about the name from the perspective of
the language. Specifically, each language now implements a
`GetFunctionNameInfo` method which returns an object of type
`Language::FunctionNameInfo`. Right now, it consists of a basename,
a context, and a FunctionNameType. Module::LookupInfo's constructor will
call `GetFunctionNameInfo` with the appropriate language plugin(s) and
then decide what to do with that information. I have attempted to maintain
existing behavior as best as possible.
A nice side effect of this change is that lldbCore no longer links
against the ObjC Language plugin.
Differential Revision: https://reviews.llvm.org/D108229
This patch handles the up and down keys if they weren't handled by the
selected field. Moreover, it makes sure the form always absorb the key
to take full control until the form is canceled or submitted.
Differential Revision: https://reviews.llvm.org/D108414
This patch adds a new key ALt+Enter key combination to form windows.
Once invoked, the first action is executed without having to navigate to
its button.
Field exit callbacks are now also invoked on validation to support this
aforementioned key combination.
One concern for this key combination is its potential use by the window
manager of the host. I am not sure if this will be a problem, but it is
worth putting in consideration.
Differential Revision: https://reviews.llvm.org/D108410
This patch adds many new keys to the text field and implements new
behaviors as follows:
```
case KEY_HOME:
case KEY_CTRL_A:
MoveCursorToStart();
case KEY_END:
case KEY_CTRL_E:
MoveCursorToEnd();
case KEY_RIGHT:
case KEY_SF:
MoveCursorRight();
case KEY_LEFT:
case KEY_SR:
MoveCursorLeft();
case KEY_BACKSPACE:
case KEY_DELETE:
RemovePreviousChar();
case KEY_DC:
RemoveNextChar();
case KEY_EOL:
case KEY_CTRL_K:
ClearToEnd();
case KEY_DL:
case KEY_CLEAR:
Clear();
```
This patch also refactors scrolling to be dynamic at draw time for
easier handing.
Differential Revision: https://reviews.llvm.org/D108385
This patch adds the support to close all inherited fds into the child
process by iterating over /proc/self/fd entries.
Differential Revision: https://reviews.llvm.org/D105732
This patch handles the return key for compound fields like lists and
mapping fields. The return key, if not handled by the field will select
the next primary element, skipping secondary elements like remove
buttons and the like.
Differential Revision: https://reviews.llvm.org/D108331
This patch adds a process launch form. Additionally, a LazyBoolean field
was implemented and numerous utility methods were added to various
fields to get the launch form working.
Differential Revision: https://reviews.llvm.org/D107869
The isprint libc function was used to determine if the key code
represents a printable character. The problem is that the specification
leaves the behavior undefined if the key is not representable as an
unsigned char, which is the case for many ncurses keys. This patch adds
and explicit check for this undefined behavior and make it consistent.
The llvm::isPrint function didn't work correctly for some reason, most
likely because it takes a char instead of an int, which I guess makes it
unsuitable for checking ncurses key codes.
Reviewed By: clayborg
Differential Revision: https://reviews.llvm.org/D108327
This patch adds a breakpoints window that lists all breakpoints and
breakpoints locations. The window is implemented as a tree, where the
first level is the breakpoints and the second level is breakpoints
locations.
The tree delegate was hardcoded to only draw when there is a process,
which is not necessary for breakpoints, so the relevant logic was
abstracted in the TreeDelegateShouldDraw method.
Reviewed By: clayborg
Differential Revision: https://reviews.llvm.org/D107386
This patch adds a new method SubSurface to the Surface class. The method
returns another surface that is a subset of this surface. This is
important to further abstract away drawing from the ncurses objects. For
instance, fields could previously be drawn on subpads only but can now
be drawn on any surface. This is needed to create the file search
dialogs and similar functionalities.
There is an opportunity to refactor window drawing in general using
surfaces, but we shall consider this separately later.
Differential Revision: https://reviews.llvm.org/D107761
Fix D98289 so that it works even for 2nd..nth compilation unit
(.debug_rnglists).
Reviewed By: dblaikie, ikudrin
Differential Revision: https://reviews.llvm.org/D106466
LLDB is using LLVM's target-specific disassembler which is only available when
the respective LLVM target has been enabled in the build config.
This patch just skips the test if there is no arm64 target (and its
disassembler) available in the current build config.
Reviewed By: jasonmolenda
Differential Revision: https://reviews.llvm.org/D108145
In 9ea6dd5cfa /
https://reviews.llvm.org/D88387 where I added skinny corefile
creation, I added new SB API and tried to manually update the hooks
for the reproducers. I missed a spot, and I should have used
lldb-instr to update the instrumentation automatically.
When assertions are turned off, the `llvm::Error` value created at the
start of this function is overwritten using the move-assignment
operator, but the success value is never checked. Whenever a TypeSystem
cannot be found or created, this can lead to lldb core dumping with:
Program aborted due to an unhandled Error:
Error value was Success. (Note: Success values must still be checked prior to being destroyed).
Fix this by not creating a `llvm::Error` value in advance, and directly
returning the result of `llvm::make_error` instead, whenever an error is
encountered.
See also: <https://bugs.freebsd.org/253881> and
<https://bugs.freebsd.org/257829>.
Reviewed By: teemperor
Differential Revision: https://reviews.llvm.org/D108088
When cross compiling lldb-server, do not create a host build
for building lldb-tblgeb when LLDB_TABLEGEN_EXE is already
provided. This avoids an expensive and time-consuming build step
if lldb-tblgen was already built previously for host.
Reviewed By: JDevlieghere
Differential Revision: https://reviews.llvm.org/D108053
On aarch64 a two instruction sequence is used to calculate a
pc-relative address, add some state to the DisassemblerLLVMC
symbolicator so it can track the necessary data across the
two instructions and compute the address being calculated.
Differential Revision: https://reviews.llvm.org/D107213
rdar://49119253
Follow up on https://reviews.llvm.org/D105741
- Add new test that exhaustively checks the output file's content
- Fix typos in documentation and other minor fixes
Reviewed By: wallace
Original Author: jj10306
Differential Revision: https://reviews.llvm.org/D107674
These two tests, TestSkinnyCorefile.py and TestStackCorefile.py,
require a new debugserver on darwin systems to run correctly; for now,
skip them if the system debugserver is in use. There's no easy way to
test if the debugserver being used supports either of these memory
region info features. For end users, the fallback will be a full
corefile and that's not the worst thing, but for the tests it is a
problem.
The benefit of using assertIn is an improved error message when the
assertion fails:
AssertionError: False is not True
becomes
AssertionError: 'have ints 5 20 20 5' not found in '""'
Add a field to the qMemoryRegionInfo packet where the remote stub
can describe the type of memory -- heap, stack. Keep track of
memory regions that are stack memory in lldb. Add a new "--style
stack" to process save-core to request that only stack memory be
included in the corefile.
Differential Revision: https://reviews.llvm.org/D107625
This patch should fix the use-after-free error that was brought up by
the LLDB ASAN Green Dragon bot.
This is caused because the `StringRef` object was acquired too early
before being use and by the underlying memory was modified which caused
it to point to null memory.
Fetching back the string reference close to its usage location should
fix the issue.
Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
This test is specifying the lldb log channel via `ll""db` which only really works
because the command parser ends up parsing that as `lldb`. Just putting the
channel name in quotes is enough to avoid the lldb command substitution and
doesn't rely on this weird parser behaviour.
Some files still contained the old University of Illinois Open Source
Licence header. This patch replaces that with the Apache 2 with LLVM
Exception licence.
Differential Revision: https://reviews.llvm.org/D107528
Skeleton vs. DWO units mismatch has been fixed in D106270. As they both
have type DWARFUnit it is a bit difficult to debug. So it is better to
make it safe against future changes.
Reviewed By: kimanh, clayborg
Differential Revision: https://reviews.llvm.org/D107659
LLDB evaluates some utility expression to update the Objective-C class list that
ends up calling function such as `free` or `objc_copyRealizedClassList_nolock`.
This adds a test that just tries to define our own bogus version of
`objc_copyRealizedClassList_nolock`. It just tests that LLDB doesn't crash as we
currently don't have a way to tell LLDB to look for the function in a specific
library.
Reviewed By: JDevlieghere
Differential Revision: https://reviews.llvm.org/D107778
We recently had an issue where a user declared a `Class::free` function which
then got picked up by accident by the expression evaluator when calling
`::free`. This was due to a too lax filter in the DWARFIndex (which was fixed by
https://reviews.llvm.org/D73191 ). This broke the Objective-C utility expression
that is trying to update the Objective-C class list (which is calling `:;free`).
This adds a regression test for situations where we have a bunch of functions
defined that share the name of the global functions that this utility function
calls. None of them are actually conflicting with the global functions we are
trying to call (they are all in namespaces, objects or classes).
Reviewed By: JDevlieghere
Differential Revision: https://reviews.llvm.org/D107776
Add a LLVM_LIT_ARGS cached variable in order to make it possible
to override lit arguments when doing standalone builds. Without that,
the user variable is ignored and the default options are always used.
Based on a similar solution found in clang.
Differential Revision: https://reviews.llvm.org/D107700
Some LD_PRELOAD-ed libraries tend to interact badly with --nodefaultlib,
particularly Gentoo sandbox. Do not run this test if LD_PRELOAD is
present in the running environment.
Differential Revision: https://reviews.llvm.org/D107701
When going through the CU entries in the name index,
make sure to compare the name entry's CU
offset against the skeleton CU's offset.
Previously there would be a mismatch, since the
wrong offset was compared, and thus no suitable
entry was found.
Reviewed By: jankratochvil
Differential Revision: https://reviews.llvm.org/D106270
Use hexadecimal numbers rather than decimal in various vFile packets
in order to fix compatibility with gdbserver. This also changes the few
custom LLDB packets -- while technically they do not have to be changed,
it is easier to use the same syntax consistently across LLDB.
Differential Revision: https://reviews.llvm.org/D107475
Sync the mode constants used to drive vFile:open requests with these
used by GDB and defined for the gdb remote protocol. This makes it
possible to use 'platform file open' after connecting to gdbremote
server (and to some degree to operate on the open file modulo other
incompatibilities).
Differential Revision: https://reviews.llvm.org/D106985
Modify OpenOptions enum to open the future path into synchronizing
vFile:open bits with GDB. Currently, LLDB and GDB use different flag
models effectively making it impossible to match bits. Notably, LLDB
uses two bits to indicate read and write status, and uses union of both
for read/write. GDB uses a value of 0 for read-only, 1 for write-only
and 2 for read/write.
In order to future-proof the code for the GDB variant:
1. Add a distinct eOpenOptionReadWrite constant to be used instead
of (eOpenOptionRead | eOpenOptionWrite) when R/W access is required.
2. Rename eOpenOptionRead and eOpenOptionWrite to eOpenOptionReadOnly
and eOpenOptionWriteOnly respectively, to make it clear that they
do not mean to be combined and require update to all call sites.
3. Use the intersection of all three flags when matching against
the three possible values.
This commit does not change the actual bits used by LLDB.
Differential Revision: https://reviews.llvm.org/D106984
Following tests fail on Arm/AArch64 randomly with timeouts:
TestMultilineNavigation.py
TestBatchMode.py
TestUnicode.py
TestGdbRemote_vContThreads.py
I am marking them as skipped until we find a away make to pass reliably.
Move Objective-C constants into ObjCConstants.h and share them between
Cocoa and AppleObjCTypeEncodingParser.
Differential revision: https://reviews.llvm.org/D107679
Upstream support for NSConstantArray, NSConstantIntegerNumber,
NSConstant{Float,Double}Number and NSConstantDictionary.
We would've upstreamed this earlier but testing it requires
-fno-constant-nsnumber-literals, -fno-constant-nsarray-literals and
-fno-constant-nsdictionary-literals which haven't been upstreamed yet.
As a temporary workaround use the system compiler (xcrun clang) for the
constant variant of the tests.
I'm just upstreaming this. The patch and the tests were all authored by
Fred Riss.
Differential revision: https://reviews.llvm.org/D107660
This reverts commit 34d78b6a67.
This breaks build bots witha missing file:
/home/worker/2.0.1/lldb-x86_64-debian/llvm-project/lldb/source/Plugins/Language/ObjC/Cocoa.cpp:10:10: fatal error: 'objc/runtime.h' file not found
The pointer to the dyld trie data structure which lldb needs to parse to get
"trampoline kinds" on Darwin used to be a field in the LC_DYLD_INFO load command. A
new load command was added recently dedicated to this purpose: LC_DYLD_EXPORTS_TRIE.
The format of the trie did not change, however. So all we have to do is use the new
command if present. The commands are supposed to be mutually exclusive, so I added
an lldb_assert to warn if they are not.
Differential Revision: https://reviews.llvm.org/D107673
Upstream support for NSConstantArray, NSConstantIntegerNumber,
NSConstant{Float,Double}Number and NSConstantDictionary.
We would've upstreamed this earlier but testing it requires
-fno-constant-nsnumber-literals, -fno-constant-nsarray-literals and
-fno-constant-nsdictionary-literals which haven't been upstreamed yet.
As a temporary workaround use the system compiler (xcrun clang) for the
constant variant of the tests.
I'm just upstreaming this. The patch and the tests were all authored by
Fred Riss.
Differential revision: https://reviews.llvm.org/D107660
This provides a convenient way to limit a breakpoint
to the current thread when setting it from the command line w/o
having to figure out what the current thread is.
Differential Revision: https://reviews.llvm.org/D107015
It looks like recent CoreFoundation builds strip the non-public symbol
that we were looking for to find the 2 boolean "classes". The public
symbol is of course there, and it contains the address of the private
one. If we don't find the private symbol directly, go through a memory
read at the public symbol's location instead.
Temporarily revert this patch to unbreak the bots/builds
until we can understand what was intended; is_pad() call
isn't defined.
This reverts commit 2b89f40a41.
This patch adds a new method SubSurface to the Surface class. The method
returns another surface that is a subset of this surface. This is
important to further abstract away drawing from the ncurses objects. For
instance, fields could previously be drawn on subpads only but can now
be drawn on any surface. This is needed to create the file search
dialogs and similar functionalities.
There is an opportunity to refactor window drawing in general using
surfaces, but we shall consider this separately later.
Reviewed By: clayborg
Differential Revision: https://reviews.llvm.org/D107182
They used to be referenced from the .xcodeproj files, but those are long gone.
No behavior change.
Differential Revision: https://reviews.llvm.org/D107444
This patch refactors IRExecutionUnit::FindInSymbols. It eliminates a few
potential pitfalls and tries to be more explicit about the state carried
between symbol resolution attempts.
Differential revision: https://reviews.llvm.org/D107206
Rather than passing two booleans around, which is especially error prone
with them being next to each other, use a struct with named fields
instead.
Differential revision: https://reviews.llvm.org/D107295
This change moves to using narrow character types and libedit APIs in
Editline, because those are the same types that the rest of LLVM/LLDB
uses, and it's generally considered better practice to use UTF-8
encoded in char than it is to use wider characters. However, for
character input, the change leaves in using a wchar to enable input of
multi-byte characters.
Differential Revision: https://reviews.llvm.org/D106035
Kazu Hirata