In macOS 12, dyld switched to using chained fixups. As a result, all symbols
are bound at launch and there are no lazy pointers any more. Since we wish to
import/dlopen() a dylib with missing symbols, we need to use a weak import.
This applies to all macOS 12-aligned OS releases, e.g. iOS 15, etc.
rdar://81295101
Differential Revision: https://reviews.llvm.org/D112034
The help string can be more helpful by explaining these are
aliases for 'process connect'
Reviewed By: JDevlieghere
Differential Revision: https://reviews.llvm.org/D111965
Use FPU_REG macro to define dN registers, removing the wrong value_regs
while at it. This is a piece-wise attempt of reconstructing D112066
with the goal of figuring out which part of the larger change breaks
the buildbot.
Differential Revision: https://reviews.llvm.org/D112066
This is a piece-wise attempt of reconstructing D112066 with the goal
of figuring out which part of the larger change breaks the buildbot.
Differential Revision: https://reviews.llvm.org/D112066
Fix incorrect values for value_regs, and incomplete values for
invalidate_regs in RegisterInfos_arm. The value_regs entry needs
to list only one base (i.e. larger) register that needs to be read
to get the value for this register, while invalidate_regs needs to list
all other registers (including pseudo-register) whose values would
change when this register is written to.
While at it, introduce helper macros for the definitions.
7a8ba4ffbe fixed a similar problem
for ARM64.
Differential Revision: https://reviews.llvm.org/D112066
Refactor ABIX86::AugmentRegisterInfo() and helper functions for better
readability. This also fixes listing eax & co. as potential subregs
on 32-bit systems.
Differential Revision: https://reviews.llvm.org/D108937
We had two sets of build<flavour> methods, whose bodies were largely
identical. This makes any kind of modification in their vicinity
repetitive and error-prone.
Replace each set with a single method taking an optional debug_info
parameter.
Differential Revision: https://reviews.llvm.org/D111989
This adds the `target dump typesystem'`command which dumps the TypeSystem of the
target itself (aka the 'scratch TypeSystem'). This is similar to `target modules
dump ast` which dumps the AST of lldb::Modules associated with a selected
target.
Unlike `target modules dump ast`, the new command is not a subcommand of `target
modules dump` as it's not touching the modules of a target at all. Also unlike
`target modules dump ast` I tried to keep the implementation language-neutral,
so this patch moves our Clang `Dump` to the `TypeSystem` interface so it will
also dump the state of any future/downstream scratch TypeSystems (e.g., Swift).
That's also why the command just refers to a 'typesystem' instead of an 'ast'
(which is only how Clang is necessarily modelling the internal TypeSystem
state).
The main motivation for this patch is that I need to write some tests that check
for duplicates in the ScratchTypeSystemClang of a target. There is currently no
way to check for this at the moment (beside measuring memory consumption of
course). It's probably also useful for debugging LLDB itself.
Reviewed By: labath
Differential Revision: https://reviews.llvm.org/D111936
When printing names in lldb on windows these names contain the full type information while on linux only the name is contained.
This change introduces a flag in the Microsoft demangler to control if the type information should be included.
With the flag enabled demangled name contains only the qualified name, e.g:
without flag -> with flag
int (*array2d)[10] -> array2d
int (*abc::array2d)[10] -> abc::array2d
const int *x -> x
For globals there is a second inconsistency which is not yet addressed by this change. On linux globals (in global namespace) are prefixed with :: while on windows they are not.
Reviewed By: teemperor, rnk
Differential Revision: https://reviews.llvm.org/D111715
`Target::GetScratchTypeSystems` returns the list of scratch TypeSystems. The
current implementation is iterating over all LanguageType values and retrieves
the respective TypeSystem for each LanguageType.
All C/C++/Obj-C LanguageTypes are however mapped to the same
ScratchTypeSystemClang instance, so the current implementation adds this single
TypeSystem instance several times to the list of TypeSystems (once for every
LanguageType that we support).
The only observable effect of this is that `SBTarget.FindTypes` for builtin
types currently queries the ScratchTypeSystemClang several times (and also adds
the same result several times).
Reviewed By: bulbazord, labath
Differential Revision: https://reviews.llvm.org/D111931
gdbserver does not expose combined ymm* registers but rather XSAVE-style
split xmm* and ymm*h portions. Extend value_regs to support combining
multiple registers and use it to create user-friendly ymm* registers
that are combined from split xmm* and ymm*h portions.
Differential Revision: https://reviews.llvm.org/D108937
Fix a potential nullptr dereference in AppleObjCRuntimeV2 by checking
the result of GetClassInfoUtilityFunction and returning a failure if
it's null.
The DynamicClassInfoExtractor was already doign the right thing, but the
SharedCacheClassInfoExtractor was missing this check.
The point is to allow users with a related set of script based commands
to organize their commands in a hierarchy in the command set, rather than
having to have only top-level commands.
Differential Revision: https://reviews.llvm.org/D110298
Refactor ConnectToRemote() to improve readability and make future
changes easier:
1. Replace static buffers with std::string.
2. When handling errors, prefer reporting the actual error over dumb
'connection status is not success'.
3. Move host/port parsing directly into reverse_connection condition
that is its only user, and simplify it to make its purpose (verifying
that a valid port is provided) clear.
4. Use llvm::errs() and llvm::outs() instead of fprintf().
Differential Revision: https://reviews.llvm.org/D111963
Adding the to be loaded dylib to the extra images causes the breakpoint
to be found in the image added to the target on Linux (though not on
Darwin). So adjust the test for this difference.
I added some tests for the case where the breakpoints take immediately
to the extant test case, and made a new test case for when the source
regex breakpoint will be set in a dlopen-ed library.
I also noticed when doing this that "lldbutil.run_to_source_breakpoint
can't handle the case where the breakpoint will be in a dlopen-ed
library, since it requires the breakpoint to have at least 1 location
before run. I fixed that by adding a parameter to say whether a
before run location is expected.
Differential Revision: https://reviews.llvm.org/D111920
Right now we only set a dependency on libc++ when the host is Darwin, which
means that libc++ in the build directory is in some undefined state when running
the test suite (it can be fully built, out-of-date or missing). Depending on
whether we have a system libc++ (which LLDB also supports running the libc++
tests against), the outcome is that we sometimes skip the libc++ tests or we run
the tests against a mix of ToT-libc++/system-libc++ (e.g., we compile against
the ToT-libc++ headers and link against the system libc++ library).
This can be demonstrated via `export LIT_FILTER=TestDataFormatterLibcxxSet ninja
check-lldb-api` (or any other libc++ test) and then gradually building parts of
libc++ in the same build (which will slowly change the test behaviour from
`UNSUPPORTED` to various failures to passing depending on how much of libcxx is
built at test time).
Note that this effectively re-enables the (unintentionally) disabled libc++
formatter tests on Linux. Don't revert this if it breaks a libc++ LLDB test,
instead please @skipIf decorate the failing test (as it was probably already
failing before this commit).
Reviewed By: labath
Differential Revision: https://reviews.llvm.org/D111981
It's been broken (not failing, but not testing anything either) for
quite some time now, and nobody noticed. It also (by design) tests
stepping through libc code, which makes it completely non-hermetic.
It's not worth reviving such a test.
Refactor ConnectToRemote() to improve readability and make future
changes easier:
1. Replace static buffers with std::string.
2. When handling errors, prefer reporting the actual error over dumb
'connection status is not success'.
3. Move host/port parsing directly into reverse_connection condition
that is its only user, and simplify it to make its purpose (verifying
that a valid port is provided) clear.
4. Use llvm::errs() and llvm::outs() instead of fprintf().
Differential Revision: https://reviews.llvm.org/D11196
Remove Status::WasInterrupted() that checks whether the underlying error
code matches EINTR. ProcessGDBRemote::ConnectToDebugserver() is its
only call site, and it does not seem correct there. After all, EINTR
is precisely when we want to retry, not stop retrying. Furthermore,
it should not really matter since we should be catching EINTR
immediately via llvm::sys::RetryAfterSignal() but that's another story.
Differential Revision: https://reviews.llvm.org/D111908
There is no reason why this function should be returning a ConstString.
While modifying these files, I also fixed several instances where
GetPluginName and GetPluginNameStatic were returning different strings.
I am not changing the return type of GetPluginNameStatic in this patch, as that
would necessitate additional changes, and this patch is big enough as it is.
Differential Revision: https://reviews.llvm.org/D111877
Right now DWARFASTParserClang::ParseSingleMember has two parts: One part parses
Objective-C properties and the other part parses C/C++ members/Objective-C
ivars. These parts are pretty much independent of each other (with one
historical exception, see below) and in practice they parse DIEs with different
tags/attributes: `DW_TAG_APPLE_property` and `DW_TAG_member`.
I don't see a good reason for keeping the different parsing code intertwined in
a single function, so instead split out the Objective-C property parser into its
own function.
Note that 90% of this commit is just unindenting nearly all of
`ParseSingleMember` which was inside a `if (tag == DW_TAG_member)` block. I.e.,
think of the old `ParseSingleMember` function as: The rest is just moving the
property parsing code into its own function and I added the ReportError
implementation in case we fail to resolve the property type (which before was
just a silent failure).
```
lang=c++
void DWARFASTParserClang::ParseSingleMember(...) {
[...]
if (tag == DW_TAG_member) {
[...] // This huge block got unindented in this patch as the `if` above is gone.
}
if (property) {
[...] // This is the property parsing code that is now its own function.
}
}
```
There is one exception to the rule that the parsers are independent. Before 2012
Objective-C properties were encoded as `DW_TAG_member` with
`DW_AT_APPLE_property*` attributes describing the property. In 2012 this has
changed in a series of commits (see for example
c0449635b3 which updates the docs) so that
`DW_TAG_APPLE_property` is now used for properties. With the old format we first
created an ivar and afterwards used the `DW_AT_APPLE_property*` attributes to
create the respective property, but there doesn't seem to be any way to create
such debug info with any clang from the last 9 years. So this is technically not
NFC in case some finds debug info from that time and tries to use properties.
Reviewed By: aprantl
Differential Revision: https://reviews.llvm.org/D111632
It seems StringConvert.cpp was moved, and the Xcode project file
wasn't updated.
Reviewed By: JDevlieghere
Differential Revision: https://reviews.llvm.org/D111910
This test starts failing when people add a setting starting with
`target.process.t` which of course can easily happen. Make it a bit more
resistant by only requiring that `target.process.thr` has a unique completion.
Fix a bug introduced while refactoring ABIAArch64::AugmentRegisterInfo()
that caused subregisters to be added even if they were already present.
Instead, abort immediately if at least one subregister is found
(following ABIX86). While at it, add a test for that.
Differential Revision: https://reviews.llvm.org/D111881
Support specifying an offset for value_regs[0], and add the offset
to the computed derived register offset. This makes it possible to
e.g. create the "ah" register on x86.
Differential Revision: https://reviews.llvm.org/D111489
When DynamicLoaderMacOS::SetNotificationBreakpoint sets the breakpoint
for new binaries being loaded/unloaded, it limits the scope of that
breakpoint to just dyld, so we don't re-evaluate the breakpoint for
every new binary loaded. I wrote this to get the module's ObjectFile
FileSpec in an earlier change, but this is not correct. If lldb
is debugging a remote system, and it had to read dyld out of memory
from the remote system, it will have no FileSpec on the lldb debugger
host. We need to grab the Module's FileSpec, which in this case is
actually falling back to the PlatformFileSpec, the binary path on the
target system.
rdar://84199646
Platform instances are stored in a function-local static list. However, the
logging code involves locking a function-local static mutex. This only works on
some implementations where the Log mutex is by accident destroyed *after* the
Platform list is destroyed.
This fixes randomly failing tests due to `recursive_mutex lock failed: Invalid
argument`.
Reviewed By: kastiglione
Differential Revision: https://reviews.llvm.org/D111816
This makes the compiler generated code for accessing the thread local
variable much simpler (no need for wrapper functions and weak pointers
to potential init functions), and can avoid toolchain bugs regarding how
to access TLS variables.
In particular, this fixes LLDB when built with current GCC/binutils for
MinGW, see https://github.com/msys2/MINGW-packages/issues/8868.
Differential Revision: https://reviews.llvm.org/D111779
When we know the bounds of the array, print any embedded nuls instead of
treating them as terminators. An exception to this rule is made for the
nul character at the very end of the string. We don't print that, as
otherwise 99% of the strings would end in \0. This way the strings
usually come out the same as how the user typed it into the compiler
(char foo[] = "with\0nuls"). It also matches how they come out in gdb.
This resolves a FIXME left from D111399, and leaves another FIXME for dealing
with nul characters in "escape-non-printables=false" mode. In this mode the
characters cause the entire summary string to be terminated prematurely.
Differential Revision: https://reviews.llvm.org/D111634
These tests fail every 10 or so runs on Windows causing both local failures as well as buildbot failures.
Differential Revision: https://reviews.llvm.org/D111659
Just moving that block inside DWARFASTParserClang::ParseChildMembers into
its own function. Also early-exiting instead of a large if when
num_attributes is 0.
Intel MPX failed to gain wide adoption and has been deprecated for a while.
GCC 9.1 removed Intel MPX support. Linux kernel removed MPX in 2019.
glibc 2.35 will remove the support.
Add necessary typemaps for Lua bindings, together with some other files.
Signed-off-by: Siger Yang <sigeryeung@gmail.com>
Reviewed By: tammela
Differential Revision: https://reviews.llvm.org/D108090
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
Adjust the encoding and format applied to i387_ext and vec* type
registers from gdbserver to match lldb-server. Both types are now
displayed as vector of uint8 instead of float and integer formats used
before. Additionally, this fixes display of STi registers when they do
not carry floating-point data (they are also used to hold MMX vectors).
Differential Revision: https://reviews.llvm.org/D108468
Remove the redudant "0x" prefix in the "dirty-pages" key of
qMemoryRegionInfo packet. The client accepts hex values both with
and without the prefix.
Differential Revision: https://reviews.llvm.org/D110510
This reverts commits f9aba9a5af and
035217ff51.
As explained in the original commit message, this didn't have the
intended effect of improving the common LLDB use case, but still
provided a marginal improvement for the places where LLDB creates a
scoped time with a string literal.
The reason for the revert is that this change pulls in the os/signpost.h
header in Signposts.h. The former transitively includes loader.h, which
contains a series of macro defines that conflict with MachO.h. There are
ways to work around that, but Adrian and I concluded that none of them
are worth the trade-off in complicating Signposts.h even further.
Add an overload of DynamicRegisterInfo::SetRegisterInfo() that accepts
a std::vector<Register> as an argument. This moves the conversion
from DRI::Register to RegisterInfo directly into DynamicRegisterInfo,
and avoids the necessity of creating fully-compatible intermediate
RegisterInfo instances.
While the new method could technically reuse AddRegister(), the ultimate
goal is to replace AddRegister() with SetRegisterInfo() entirely.
Differential Revision: https://reviews.llvm.org/D111435
Create pseudo-registers on the AArch64 target if they are not provided
by the remote server. This is the case for gdbserver. The created
registers are:
- 32-bit wN partials for 64-bit xN registers
- double precision floating-point dN registers (overlapping with vN)
- single precision floating-point sN registers (overlapping with vN)
Differential Revision: https://reviews.llvm.org/D109876
Move DynamicRegisterInfo::AddSupplementaryRegister() into a standalone
function working on std::vector<DynamicRegisterInfo::Register>.
Differential Revision: https://reviews.llvm.org/D111295
Call ABI::AugmentRegisterInfo() once with a vector of all defined
registers rather than calling it for every individual register. Move
and rename RemoteRegisterInfo from gdb-remote to
DynamicRegisterInfo::Register, and use this class when augmenting
registers.
Differential Revision: https://reviews.llvm.org/D111142
D68422 introduced `ParsedDWARFTypeAttributes` which encapsulated attribute
parsing and storage into its own small struct. This patch is doing the same for
the member type attribute parsing. One utility class is parsing normal member
attributes and the other is parsing the dedicated Objective-C property
attributes.
Right now the patch just makes the `ParseSingleMember` function a bit shorter,
but the bigger benefit is that we can now split up the function into Objective-C
property parsing and parsing of normal members (struct/class members and
Objective-C ivars). The only shared code between those two parsing logic is the
normal member attribute parsing.
Reviewed By: labath
Differential Revision: https://reviews.llvm.org/D111494
Rewrite the register reading/writing tests to use explicit qRegisterInfo
packets rather than relying on ARM registers being hardcoded in LLDB.
While at it, use x86_64 for tests -- since it was easier for me to get
the register lists from that architecture.
Differential Revision: https://reviews.llvm.org/D111496
This adds support for parsing DW_AT_calling_convention in the DWARF parser.
The generic DWARF parsing code already support extracting this attribute from A
DIE and TypeSystemClang already offers a parameter to add a calling convention
to a function type (as the PDB parser supports calling convention parsing), so
this patch just converts the DWARF enum value to the Clang enum value and adds a
few tests.
There are two tests in this patch.:
* A unit test for the added DWARF parsing code that should run on all platforms.
* An API tests that covers the whole expression evaluation machinery by trying
to call functions with non-standard calling conventions. The specific subtests
are target specific as some calling conventions only work on e.g. win32 (or, if
they work on other platforms they only really have observable differences on a
specific target). The tests are also highly compiler-specific, so if GCC or
Clang tell us that they don't support a specific calling convention then we just
skip the test.
Note that some calling conventions are supported by Clang but aren't implemented
in LLVM (e.g. `pascal`), so there we just test that if this ever gets
implemented in LLVM that LLDB works too. There are also some more tricky/obscure
conventions that are left out such as the different swift* conventions, some
planned Obj-C conventions (`Preserve*`), AAPCS* conventions (as the DWARF->Clang
conversion is ambiguous for AAPCS and APPCS-VFP) and conventions only used for
OpenCL etc.
Reviewed By: aprantl
Differential Revision: https://reviews.llvm.org/D108629
The current code just prints to the System's 'error log' which is usually stderr
(+ some other log backend). Printing to stderr however just interferes with
LLDB's console UI, so when this code is triggered during for example command
completion it just breaks the LLDB console interface until the next redraw.
Instead just use the normal LLDB log which is by default hidden and is what
users usually attach to bug reports.
The only known bug that triggers this is
https://bugs.llvm.org/show_bug.cgi?id=46775
Reviewed By: labath
Differential Revision: https://reviews.llvm.org/D111149
Combine m_read_sp and m_write_sp into a single m_io_sp. In all
currently existing code paths, they are pointing to the same object
anyway.
Differential Revision: https://reviews.llvm.org/D111396
ParseSingleMember has two large ifs around the back of it's body:
`if (!is_artificial)` and `if (member_type)`. This patch just converts those
to early-exits. The patch is NFC. It even retains the curious fact that
Objective-C properties that fail to parse are silently ignored, but now there
is at least a FIXME that points this out.
This moves the registry higher in the LLVM library dependency stack.
Every client of the target registry needs to link against MC anyway to
actually use the target, so we might as well move this out of Support.
This allows us to ensure that Support doesn't have includes from MC/*.
Differential Revision: https://reviews.llvm.org/D111454
This patch refactors Scripted Process and Scripted Thread related
classes to use LLVM_PRETTY_FUNCTION instead of the compiler macro.
Differential Revision: https://reviews.llvm.org/D111452
Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
This patch disables TestScriptedProcess.py on Linux and Windows while I
investigate the OS specific failure:
http://lab.llvm.org:8011/#/builders/68/builds/19793
Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
This patch adds support for memory regions in Scripted Processes.
This is necessary to read the stack memory region in order to
reconstruct each stackframe of the program.
In order to do so, this patch makes some changes to the SBAPI, namely:
- Add a new constructor for `SBMemoryRegionInfo` that takes arguments
such as the memory region name, address range, permissions ...
This is used when reading memory at some address to compute the offset
in the binary blob provided by the user.
- Add a `GetMemoryRegionContainingAddress` method to `SBMemoryRegionInfoList`
to simplify the access to a specific memory region.
With these changes, lldb is now able to unwind the stack and reconstruct
each frame. On top of that, reloading the target module at offset 0 allows
lldb to symbolicate the `ScriptedProcess` using debug info, similarly to an
ordinary Process.
To test this, I wrote a simple program with multiple function calls, ran it in
lldb, stopped at a leaf function and read the registers values and copied
the stack memory into a binary file. These are then used in the python script.
Differential Revision: https://reviews.llvm.org/D108953
Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
This patch introduces the `ScriptedThread` class with its python
interface.
When used with `ScriptedProcess`, `ScriptedThreaad` can provide various
information such as the thread state, stop reason or even its register
context.
This can be used to reconstruct the program stack frames using lldb's unwinder.
rdar://74503836
Differential Revision: https://reviews.llvm.org/D107585
Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
Open and use the secondary end of a pty for testing Terminal properties
in order to fix the tests on Darwin. While at it, streamline getting
the fd and Terminal class.
Differential Revision: https://reviews.llvm.org/D111402
Move the POSIX-specific fd:// and file:// scheme handling into
separate methods. Replace the custom GetURLAddress() matching with
splitting into scheme and path, and matching scheme via
llvm::StringSwitch. Use early returns.
Differential Revision: https://reviews.llvm.org/D111321
Replace separate read and write NativeFile instances with a single
instance shared for reading and writing. There is no clear indication
why two instances were used in the first place, and replacing them
with just one does not seem to cause any regressions in tests or manual
'process connect file://...'.
Differential Revision: https://reviews.llvm.org/D111314
As discussed in D109948, pre-computing all complex float types is not
necessary and brings extra overhead. This patch removes these defined
types, and construct them in-place when needed.
Reviewed By: teemperor
Differential Revision: https://reviews.llvm.org/D111387
JSON crashlogs have an optional field named reportNotes that contains
any potential errors encountered by the crash reporter when generating
the crashlog. Parse and display them in LLDB.
Differential revision: https://reviews.llvm.org/D111339
Gracefully deal with JSON crashlogs that don't have thread state
available and print an error saying as much: "No thread state (register
information) available".
rdar://83955858
Differential revision: https://reviews.llvm.org/D111341
This patch fixes:
llvm-project/lldb/source/Plugins/ABI/PowerPC/ABISysV_ppc.cpp:204:6:
error: missing field 'invalidate_regs' initializer
[-Werror,-Wmissing-field-initializers]
This has started failing since we moved our bots to Focal.
For unknown reasons the abort_caller stack is missing when
we check from the handler breakpoint.
Mark unsupported while I investigate.
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.
Vedant Kumar