We have some 500 ish uses of the bool plus ref version
so changing them all at once isn't a great idea.
This adds an overload that doesn't take a RegisterInfo&
and returns an optional.
Once I'm done switching all the existing callers I'll
remove the original function.
Benefits of optional over bool plus ref:
* The intent of the function is clear from the prototype.
* It's harder to forget to check if the return is valid,
and if you do you'll get an assert.
* You don't hide ununsed variables, which happens because
passing by ref marks a variable used.
* You can't forget to reset the RegisterInfo in between
calls.
Reviewed By: clayborg
Differential Revision: https://reviews.llvm.org/D134536
If a process has multiple threads, the thread with the stop
info might not be the first one in the thread list.
On Windows, under certain circumstances, processes seem to have
one or more extra threads that haven't been launched by the
executable itself, waiting in NtWaitForWorkViaWorkerFactory. If the
main (stopped) thread isn't the first one in the list (the order
seems nondeterministic), DidProcessStopAbnormally() would return
false prematurely, instead of inspecting later threads.
The main observable effect of DidProcessStopAbnormally() erroneously
returning false, is when running lldb with multiple "-o" parameters
to specify multiple commands to execute on the command line.
After an abnormal stop, lldb would stop executing "-o" parameters
and execute "-k" parameters instead - but due to this issue, it
would instead keep executing "-o" parameters as if there was no
abnormal stop. (If multiple parameters are specified via a script
file via the "-s" option, all of the commands in that file are
executed regardless of whether there's an abnormal stop inbetween.)
Differential Revision: https://reviews.llvm.org/D134037
There are two conditions for the loop exit. Either we hit LLDB_INVALID_ADDRESS
or the ABI tells us we are beyond mappable memory.
I made a mistake in that second part that meant if you had no ABI plugin
--all would stop on the first loop and return nothing.
If there's no ABI plugin we should only check for LLDB_INVALID_ADDRESS.
Depends on D134029
Reviewed By: labath
Differential Revision: https://reviews.llvm.org/D134030
When I wrote the initial version I forgot that a region being
unmapped is not an error. There are real errors that we don't
want to hide, such as the remote not supporting the
qMemoryRegionInfo packet (gdbserver does not).
Reviewed By: labath
Differential Revision: https://reviews.llvm.org/D134029
The motivating issue was the following:
```
$ cat main.cpp
enum class EnumVals : uint16_t {
VAL1 = 0
};
struct Foo {
EnumVals b1 : 4;
};
int main() {
// Assign value out-of-range if
// bit-field were signed
Foo f{.b1 = (EnumVals)8};
return 0; // Break here
}
(lldb) script
>>> lldb.frame.FindVariable("f").GetChildMemberWithName("b1").GetValueAsUnsigned()
4294967288
```
In the above example we observe a unsigned integer wrap-around
because we sign-extended the bit-fields underlying Scalar value
before casting it to an unsigned. The sign extension occurs because
we don't mark APSInt::IsUnsigned == true correctly when extracting
the value from memory (in Value::ResolveValue). The reason why sign
extension causes the wraparound is that the value we're assigning
to the bit-field is out-of-range (if it were a signed bit-field),
which causes `Scalar::sext` to left-fill the Scalar with 1s.
This patch corrects GetEncoding to account for unsigned enum types.
With this change the Scalar would be zero-extended instead.
This is mainly a convenience fix which well-formed code wouldn't
encounter.
rdar://99785324
Differential Revision: https://reviews.llvm.org/D134493
This patch adds auto source map deduce count as a target level statistics.
This will help telemetry to track how many debug sessions benefit from this feature.
Differential Revision: https://reviews.llvm.org/D134483
When debugging using Fission (-gsplit-dwarf), we can sometimes have issues loading .dwo files if they are missing or if the path was relative and we were unable to locate the file. We can also skip loading due to DWO ID mismatch or if a .dwp file doesn't contain a matching .dwo file. Also .dwo files could be updated due to a recompile and if the user debugs an executable that was linked against the old .dwo file, it could fail to load the information.
This patch adds a m_dwo_error to DWARFUnit that can be get/set and will cause "frame variable" to show errors when there are .dwo/.dwp issues informing the user about the error.
Differential Revision: https://reviews.llvm.org/D134252
- Merge pairs like `eFormatCategoryItemSummary` and
`eFormatCategoryItemRegexSummary` into a single value. See explanation
below.
- Rename `eFormatCategoryItemValue` to `eFormatCategoryItemFormat`. This
makes the enum match the names used elsewhere for formatter kinds
(format, summary, filter, synth).
- Delete unused values `eFormatCategoryItemValidator` and
`eFormatCategoryItemRegexValidator`.
This enum is only used to reuse some code in CommandObjectType.cpp. For
example, instead of having separate implementations for `type summary
delete`, `type format delete`, and so on, there's a single generic
implementation that takes an enum value, and then the specific commands
derive from it and set the right flags for the specific kind of
formatter.
Even though the enum distinguishes between regular and regex matches for
every kind of formatter, this distinction is never used: enum values are
always specified in pairs like
`eFormatCategoryItemSummary | eFormatCategoryItemRegexSummary`.
This causes some ugly code duplication in TypeCategory.cpp. In order to
handle every flag combination some code appears 8 times:
{format, summary, synth, filter} x {exact, regex}
Differential Revision: https://reviews.llvm.org/D134244
This happens if the type is described elsewhere in target xml as a
<flags> or <struct>.
Also hardcode the function names into the log messages because
if you use __FUNCTION__ in a lambda you just get "operator()".
Reviewed By: clayborg
Differential Revision: https://reviews.llvm.org/D134043
This is the first step to being able to handle non
trivial types in the union.
info_type effects the lifetime of the objects in the union,
so making it private means we know you have to call one of the
Set<...> functions to change it.
Reviewed By: clayborg
Differential Revision: https://reviews.llvm.org/D134039
So that the XML isn't one giant line. Which wasn't
a problem for lldb but was for me trying to troubleshoot
it using the logs.
It now looks like:
```
<?xml version="1.0"?>
<target version="1.0">
<architecture>aarch64</architecture>
<feature>
<...>
<reg name="fpcr" .../>
</feature>
</target>
```
Reviewed By: labath
Differential Revision: https://reviews.llvm.org/D134035
In January, Greg put up a patch (D117382) to support, among other
things, more than 32 log categories. That led to a bunch of nice
cleanups, but categories remained constrained because different parts of
the code were still using uint32_t. This patch fixes the remaining
issues and makes it possible to add a 32nd log category.
Differential revision: https://reviews.llvm.org/D134245
This patch adds a new "target.auto-source-map-relative" setting.
If enabled, this setting may auto deduce a source map entry based on requested
breakpoint path and the original path stored in debug info for resolved
breakpoint.
As an example, if debug info contains "./a/b/c/main.cpp", user sets a source
breakpoint at "/root/repo/x/y/z/a/b/c/main.cpp". The breakpoint will resolve
correctly now with Greg's patch https://reviews.llvm.org/D130401. However, the
resolved breakpoint will use "./a/b/c/main.cpp" to locate source file during
stop event which would fail most of the time.
With the new "target.auto-source-map-relative" setting enabled, a auto deduced
source map entry "." => "/root/repo/x/y/z" will be added. This new mapping will
help lldb to map resolved breakpoint path "./a/b/c/main.cpp" back to
"/root/repo/x/y/z/a/b/c/main.cpp" and locate it on disk.
If an existing source map entry is used the patch also concatenates the auto
deduced entry with any stripped reverse mapping prefix (see example below).
As a second example, debug info contains "./a/b/c/main.cpp" and user sets
breakpoint at "/root/repo/x/y/z/a/b/c/main.cpp". Let's say there is an existing
source map entry "." => "/root/repo"; this mapping would strip the prefix out of
"/root/repo/x/y/z/a/b/c/main.cpp" and use "x/y/z/a/b/c/main.cpp" to resolve
breakpoint. "target.auto-source-map-relative" setting would auto deduce a new
potential mapping of "." => "x/y/z", then it detects that there is a stripped
prefix from reverse mapping and concatenates it as the new mapping:
"." => "/root/repo/x/y/z" which would correct map "./a/b/c/main.cpp" path to
new path in disk.
This patches depends on https://reviews.llvm.org/D130401 to use new added
SBDebugger::GetSetting() API for testing.
Differential Revision: https://reviews.llvm.org/D133042
A common debugging pattern is to set a breakpoint that only stops after
a number of hits is recorded. The current implementation never resets
the hit count of breakpoints; as such, if a user re-`run`s their
program, the debugger will never stop on such a breakpoint again.
This behavior is arguably undesirable, as it renders such breakpoints
ineffective on all but the first run. This commit changes the
implementation of the `Will{Launch, Attach}` methods so that they reset
the _target's_ breakpoint hitcounts.
Differential Revision: https://reviews.llvm.org/D133858
Before, it returns the outermost blocks if nested blocks have the same
address range. That casuses lldb unable to find variables that are inside
inner blocks.
Reviewed By: labath
Differential Revision: https://reviews.llvm.org/D133601
The uncached lookup is mainly used in the ASTImporter/LLDB code-path
where we're not allowed to load from external storage. When importing
a FieldDecl with a DeclContext that had no external visible storage
(but came from a Clang module or PCH) the above call to `lookup(Name)`
the regular `DeclContext::lookup` fails because:
1. `DeclContext::buildLookup` doesn't set `LookupPtr` for decls
that came from a module
2. LLDB doesn't use the `SharedImporterState`
In such a case we would never continue with the "slow" path of iterating
through the decl chain on the DeclContext. In some cases this means that
ASTNodeImporter::VisitFieldDecl ends up importing a decl into the
DeclContext a second time.
The patch removes the short-circuit in the case where we don't find
any decls via the regular lookup.
**Tests**
* Un-skip the failing LLDB API tests
Differential Revision: https://reviews.llvm.org/D133945
The problem here is that the ASTImporter adds
the template class member FieldDecl to
the DeclContext twice. This happens because
we don't construct a `LookupPtr` for decls
that originate from modules and thus the
ASTImporter never realizes that the FieldDecl
has already been imported. These duplicate
decls then break the assumption of the LayoutBuilder
which expects only a single member decl to
exist.
The test will be fixed by a follow-up revision
and is thus skipped for now.
Differential Revision: https://reviews.llvm.org/D133944
When attempting to use SWIG's `-builtin` flag, there were a few compile
failures caused by a mismatch between return type and return value. In those
cases, the return type was `int` but many of the type maps assume returning
`NULL`/`nullptr` (only the latter caused compile failures).
This fix abstracts failure paths to use the `SWIG_fail` macro, which performs
`goto fail;`. Each of the generated functions contain a `fail` label, which
performs any resource cleanup and returns the appropriate failure value.
This change isn't strictly necessary at this point, but seems like the right
thing to do, and for anyone who tries `-builtin` later, it resolves those
issues.
Differential Revision: https://reviews.llvm.org/D133961
For this patch, a simple search was performed for patterns where there are
two types (usually an LHS and an RHS) which are structurally the same, and there
is some result type which is resolved as either one of them (typically LHS for
consistency).
We change those cases to resolve as the common sugared type between those two,
utilizing the new infrastructure created for this purpose.
Signed-off-by: Matheus Izvekov <mizvekov@gmail.com>
Differential Revision: https://reviews.llvm.org/D111509
For this patch, a simple search was performed for patterns where there are
two types (usually an LHS and an RHS) which are structurally the same, and there
is some result type which is resolved as either one of them (typically LHS for
consistency).
We change those cases to resolve as the common sugared type between those two,
utilizing the new infrastructure created for this purpose.
Signed-off-by: Matheus Izvekov <mizvekov@gmail.com>
Differential Revision: https://reviews.llvm.org/D111509
This reverts commit ac05bc0524.
I had incorrectly removed one set of checks in the option handling in
Options::ParseAlias because I couldn't see what it is for. It was a
bit obscure, but it handled the case where you pass "-something=other --"
as the input_line, which caused the built-in "run" alias not to return
the right value for IsDashDashCommand, causing TestHelp.py to fail.
A simple sed doing these substitutions:
- `${LLVM_BINARY_DIR}/lib${LLVM_LIBDIR_SUFFIX}\>` -> `${LLVM_LIBRARY_DIR}`
- `${LLVM_BINARY_DIR}/bin\>` -> `${LLVM_TOOLS_BINARY_DIR}`
where `\>` means "word boundary".
The only manual modifications were reverting changes in
- `runtimes/CMakeLists.txt`
because these were "entry points" where we wanted to tread carefully not not introduce a "loop" which would end with an undefined variable being expanded to nothing.
There are some `${LLVM_BINARY_DIR}/lib` without the `${LLVM_LIBDIR_SUFFIX}`, but these refer to the lib subdirectory of the source (`llvm/lib`). That `lib` is automatically appended to make the local `CMAKE_CURRENT_BINARY_DIR` value by `add_subdirectory`; since the directory name in the source tree is fixed without any suffix, the corresponding `CMAKE_CURRENT_BINARY_DIR` will also be. We therefore do not replace it but leave it as-is.
This picks up where D133828 left off, getting the occurrences with*out* `CMAKE_CFG_INTDIR`. But this is difficult to do correctly and so not done in the (retroactively) previous diff.
This hopefully increases readability overall, and also decreases the usages of `LLVM_LIBDIR_SUFFIX`, preparing us for D130586.
Reviewed By: sebastian-ne
Differential Revision: https://reviews.llvm.org/D132316
A simple sed doing these substitutions:
- `${LLVM_BINARY_DIR}/\$\{CMAKE_CFG_INTDIR}/lib(${LLVM_LIBDIR_SUFFIX})?\>` -> `${LLVM_LIBRARY_DIR}`
- `${LLVM_BINARY_DIR}/\$\{CMAKE_CFG_INTDIR}/bin\>` -> `${LLVM_TOOLS_BINARY_DIR}`
where `\>` means "word boundary".
The only manual modifications were reverting changes in
- `compiler-rt/cmake/Modules/CompilerRTUtils.cmake`
because these were "entry points" where we wanted to tread carefully not not introduce a "loop" which would end with an undefined variable being expanded to nothing.
There are many more occurrences without `CMAKE_CFG_INTDIR`, but those are left for D132316 as they have proved somewhat tricky to fix.
This hopefully increases readability overall, and also decreases the usages of `LLVM_LIBDIR_SUFFIX`, preparing us for D130586.
Reviewed By: sebastian-ne
Differential Revision: https://reviews.llvm.org/D133828
D131437 caused heap-use-after-free failures when testing TestCreateAfterAttach.py in asan mode, and "regular" crashes outside of asan.
This appears to be due to a mismatch in a couple places where we choose to clear the DIEs. When we clear the DIE of a skeleton unit, we unconditionally clear the DIE of the DWO unit if it exists. However, `~ScopedExtractDIEs()` only looks at the skeleton unit when deciding to clear. If we decide to clear the skeleton unit because it is now unused, we end up clearing the DWO unit that _is_ used. This change adds a guard by checking `m_cancel_scopes` to prevent clearing the DWO unit.
This is 100% reproducible by running TestCreateAfterAttach.py in asan mode, although it only seems to reproduce in our internal build, so no test case is added here. If someone has suggestions on how to write one, I can add it.
Reviewed By: labath
Differential Revision: https://reviews.llvm.org/D133790
These are passing now that the relocation assertion has been removed in
D132954.
Relocations still remain unimplemented though, so it's possible this may
start to fail due to unrelated changes. If that happens very often, we
may just need to disable (skip) the test instead.
Add support for recognizing a platform binary in the ObjectFileMachO
method that parses the "load binary" LC_NOTEs in a corefile.
A bit of reorganization to ProcessMachCore::DoLoadCore to separate
all of the unrelated things being done in that method into their own
separate methods, as well as small fixes to improve the handling of
a corefile with multiple kernel images in the corefile.
Differential Revision: https://reviews.llvm.org/D133680
rdar://98754861
The expression fuzzer checks an environment variable, `LLDB_FUZZER_TARGET`, to get the fuzzer target binary. This is fine, but internally our tooling for running fuzz tests only has proper handling for flag values. It's surprisingly complicated to add support for that, and allowing it to be passed via flag seems reasonable anyway.
Reviewed By: cassanova
Differential Revision: https://reviews.llvm.org/D133546
This reverts commit 6c089b2af5.
This was causing the test test_help_run_hides_options from TestHelp.py to
fail on Linux and Windows (but the test succeeds on macOS). The decision
to print option information is determined by CommandObjectAlias::IsDashDashCommand
which was changed, but only by replacing an inline string constant with a const char *
CommandInterpreter::g_argument which has the same string value. I can't see why this
would fail, I'll have to spin up a vm to see if I can repo there.
Sadly, the test passes on macOS, but fails on Ubuntu & Win. The
extra option printing is supposed to be suppressed by the return
from CommandObjectAlias::IsDashDashCommand. That was changed, but just
by replacing an inline string compare with a const string from
CommandInterpreter. Putting the old version back temporarily to
see if that is really the problem.
Modify `SBTypeNameSpecifier` and `lldb_private::TypeMatcher` so they
have an enum value for the type of matching to perform instead of an
`m_is_regex` boolean value.
This change paves the way for introducing formatter matching based on
the result of a python callback in addition to the existing name-based
matching. See the RFC thread at
https://discourse.llvm.org/t/rfc-python-callback-for-data-formatters-type-matching/64204
for more details.
Differential Revision: https://reviews.llvm.org/D133240
This is particularly a problem for alias construction, where you might
want to have a backtick surrounded option in the alias. Before this
patch:
command alias expression -Z \`argc\` -- argv
for instance would be rendered as:
expression -Z argc -- argv
and would fail to work.
Differential Revision: https://reviews.llvm.org/D133045
I went over the output of the following mess of a command:
(ulimit -m 2000000; ulimit -v 2000000; git ls-files -z | parallel
--xargs -0 cat | aspell list --mode=none --ignore-case | grep -E
'^[A-Za-z][a-z]*$' | sort | uniq -c | sort -n | grep -vE '.{25}' |
aspell pipe -W3 | grep : | cut -d' ' -f2 | less)
and proceeded to spend a few days looking at it to find probable typos
and fixed a few hundred of them in all of the llvm project (note, the
ones I found are not anywhere near all of them, but it seems like a
good start).
Differential revision: https://reviews.llvm.org/D131122
I encountered an issue where `p &variable` was finding an incorrect address for
32-bit PIC ELF files loaded into a running process. The problem was that the
R_386_32 ELF relocations were not being applied to the DWARF section, so all
variables in that file were reporting as being at the start of their respective
section. There is an assert that catches this on debug builds, but silently
ignores the issue on non-debug builds.
In this changeset, I added handling for the R_386_32 relocation type to
ObjectFileELF, and a supporting function to ELFRelocation to differentiate
between DT_REL & DT_RELA in ObjectFileELF::ApplyRelocations().
Demonstration of issue:
```
[dmlary@host work]$ cat rel.c
volatile char padding[32] = "make sure var isnt at .data+0";
volatile char var[] = "test";
[dmlary@host work]$ gcc -c rel.c -FPIC -fpic -g -m32
[dmlary@host work]$ lldb ./exec
(lldb) target create "./exec"
Current executable set to '/home/dmlary/src/work/exec' (i386).
(lldb) process launch --stop-at-entry
Process 21278 stopped
* thread #1, name = 'exec', stop reason = signal SIGSTOP
frame #0: 0xf7fdb150 ld-2.17.so`_start
ld-2.17.so`_start:
-> 0xf7fdb150 <+0>: movl %esp, %eax
0xf7fdb152 <+2>: calll 0xf7fdb990 ; _dl_start
ld-2.17.so`_dl_start_user:
0xf7fdb157 <+0>: movl %eax, %edi
0xf7fdb159 <+2>: calll 0xf7fdb140
Process 21278 launched: '/home/dmlary/src/work/exec' (i386)
(lldb) image add ./rel.o
(lldb) image load --file rel.o .text 0x40000000 .data 0x50000000
section '.text' loaded at 0x40000000
section '.data' loaded at 0x50000000
(lldb) image dump symtab rel.o
Symtab, file = rel.o, num_symbols = 13:
Debug symbol
|Synthetic symbol
||Externally Visible
|||
Index UserID DSX Type File Address/Value Load Address Size Flags Name
------- ------ --- --------------- ------------------ ------------------ ------------------ ---------- ----------------------------------
[ 0] 1 SourceFile 0x0000000000000000 0x0000000000000000 0x00000004 rel.c
[ 1] 2 Invalid 0x0000000000000000 0x0000000000000020 0x00000003
[ 2] 3 Invalid 0x0000000000000000 0x50000000 0x0000000000000020 0x00000003
[ 3] 4 Invalid 0x0000000000000025 0x0000000000000000 0x00000003
[ 4] 5 Invalid 0x0000000000000000 0x0000000000000020 0x00000003
[ 5] 6 Invalid 0x0000000000000000 0x0000000000000020 0x00000003
[ 6] 7 Invalid 0x0000000000000000 0x0000000000000020 0x00000003
[ 7] 8 Invalid 0x0000000000000000 0x0000000000000020 0x00000003
[ 8] 9 Invalid 0x0000000000000000 0x0000000000000020 0x00000003
[ 9] 10 Invalid 0x0000000000000000 0x0000000000000020 0x00000003
[ 10] 11 Invalid 0x0000000000000000 0x0000000000000020 0x00000003
[ 11] 12 X Data 0x0000000000000000 0x50000000 0x0000000000000020 0x00000011 padding
[ 12] 13 X Data 0x0000000000000020 0x50000020 0x0000000000000005 0x00000011 var
(lldb) p &var
(volatile char (*)[5]) $1 = 0x50000000
```
Reviewed By: labath
Differential Revision: https://reviews.llvm.org/D132954
While auxv keys are usually small, e.g. less than 50, they can sometimes be larger, especially on a downstream kernel where a custom auxv entry is intentionally high to avoid conflicting with the standard lower numbers. This test fails on a system with an auxv value bigger than 1000, but instead of putting this test at that value plus one, it looks like 2023 (i.e. `AT_SUN_CAP_HW2`) is another large one out there. Use 2500 as a limit to still have this be a reasonable "small" check but still allow all known auxv keys.
Semi-related change: this test case prints the auxv dict at the trace level, but only _after_ the assertion fails, making it not print what the offending value is as the test case aborts. Move it earlier so we can see what the "unreasonable" auxv value is.
Debugging some DWARF5 binaries was causing errors to appear when DWARFExpression::Evaluate was called:
error: GetDIE for DIE 0x31 is outside of its CU 0x123450
The issue is in the DWARF expression evaluator. Fixed with this.
Differential Revision: https://reviews.llvm.org/D133623
Summary:
Many times when debugging variables might not be available even though a user can successfully set breakpoints and stops somewhere. Letting the user know will help users fix these kinds of issues and have a better debugging experience.
Examples of this include:
- enabling -gline-tables-only and being able to set file and line breakpoints and yet see no variables
- unable to open object file for DWARF in .o file debugging for darwin targets due to modification time mismatch or not being able to locate the N_OSO file.
This patch adds an new API to SBValueList:
lldb::SBError lldb::SBValueList::GetError();
object so that if you request a stack frame's variables using SBValueList SBFrame::GetVariables(...), you can get an error the describes why the variables were not available.
This patch adds the ability to get an error back when requesting variables from a lldb_private::StackFrame when calling GetVariableList.
It also now shows an error in response to "frame variable" if we have debug info and are unable to get varialbes due to an error as mentioned above:
(lldb) frame variable
error: "a.o" object from the "/tmp/libfoo.a" archive: either the .o file doesn't exist in the archive or the modification time (0x63111541) of the .o file doesn't match
Reviewers: labath JDevlieghere aadsm yinghuitan jdoerfert sscalpone
Subscribers:
Differential Revision: https://reviews.llvm.org/D133164
This commit improves upon cc0b5ebf7f, which added support for
specifying which libcxx to use when testing LLDB. That patch honored
requests by tests that had `USE_LIBCPP=1` defined in their makefiles.
Now, we also use a non-default libcxx if all conditions below are true:
1. The test is not explicitly requesting the use of libstdcpp
(USE_LIBSTDCPP=1).
2. The test is not explicitly requesting the use of the system's
library (USE_SYSTEM_STDLIB=1).
3. A path to libcxx was either provided by the user through CMake flags
or libcxx was built together with LLDB.
Condition (2) is new and introduced in this patch in order to support
tests that are either:
* Cross-platform (such as API/macosx/macCatalyst and
API/tools/lldb-server). The just-built libcxx is usually not built for
platforms other than the host's.
* Cross-language (such as API/lang/objc/exceptions). In this case, the
Objective C runtime throws an exceptions that always goes through the
system's libcxx, instead of the just built libcxx. Fixing this would
require either changing the install-name of the just built libcxx in Mac
systems, or tuning the DYLD_LIBRARY_PATH variable at runtime.
Some other tests exposes limitations of LLDB when running with a debug
standard library. TestDbgInfoContentForwardLists had an assertion
removed, as it was checking for buggy LLDB behavior (which now
crashes). TestFixIts had a variable renamed, as the old name clashes
with a standard library name when debug info is present. This is a known
issue: https://github.com/llvm/llvm-project/issues/34391.
For `TestSBModule`, the way the "main" module is found was changed to
look for the "a.out" module, instead of relying on the index being 0. In
some systems, the index 0 is dyld when a custom standard library is
used.
Differential Revision: https://reviews.llvm.org/D132940
If we don't add local variables with no location info, when trying to print it,
lldb won't find it in the its parent DeclContext, which makes lldb to spend more
time to search all the way up in DeclContext hierarchy until found same name
variable or failed. Dwarf plugin also add local vars even if they don't have
location info.
Differential Revision: https://reviews.llvm.org/D133626
* Include SetCallback in SBBreakpointLocation, similar as in SBBreakpoint.
* Add test_breakpoint_location_callback test as part of TestMultithreaded.
Reviewed By: werat, JDevlieghere
Differential Revision: https://reviews.llvm.org/D133689
Co-authored-by: Andy Yankovsky <weratt@gmail.com>
The CMake variable LLDB_HAS_LIBCXX is passed to
`llvm_canonicalize_cmake_booleans`, which transforms TRUE/FALSE into
'1'/'0'. It also transforms undefined variables to '0'.
In particular, this means that the configuration script for LLDB API's
test always has _some_ value for the `has_libcxx` configuration:
```
config.has_libcxx = '@LLDB_HAS_LIBCXX@'
```
When deciding whether a libcxx exist, the testing scripts would only
check for the existence of `has_libcxx`, but not for its value. In other
words, because `if ('0')` is true in python we always think there is a
libcxx.
This was caught once D132940 was merged and most tests started to use
libcxx by default if `has_libcxx` is true. Prior to that, no failures
were seen because only tests are marked with
`@add_test_categories(["libc++"])` would require a libcxx, and these
would be filtered out on builds without the libcxx target. Furthermore,
the MacOS bots always build libcxx.
We fix this by making `has_libcxx` a boolean (instead of a string) and
by checking its value in the test configuration.
Differential Revision: https://reviews.llvm.org/D133639
This patch adds new SBDebugger::GetSetting() API which
enables client to access settings as SBStructedData.
Implementation wise, a new ToJSON() virtual function is added to OptionValue
class so that each concrete child class can override and provides its
own JSON representation. This patch aims to define the APIs and implement
a common set of OptionValue child classes, leaving the remaining for
future patches.
This patch is used later by auto deduce source map from source line breakpoint
feature for testing generated source map entries.
Differential Revision: https://reviews.llvm.org/D133038
This patch adds a new page to the LLDB documentation that documents,
among other things the -gmodules debug info format.
Differential Revision: https://reviews.llvm.org/D133519
DynamicLoaderDarwinKernel calls in to PlatformDarwinKernel, and
with my changes in https://reviews.llvm.org/D133534, PlatformDarwinKernel
calls in to DynamicLoaderDarwinKernel. This results in a cmake
dependency if accurately included in the link libraries list.
lldbPluginDynamicLoaderDarwinKernel is specfically for kernel
debugging and is uncommonly linked in to anything except a full
lldb. lldbPluginPlatformMacOSX is any Darwin platform, including
PlatformDarwinKernel, and is referenced a number of time in shell
tests, for instance.
I believe anything linking the darwin kernel DynamicLoader plugin
will already have lldbPluginPlatformMacOSX in its dependency list,
so not explicitly expressing this dependency is safe.
Many times when debugging variables might not be available even though a user can successfully set breakpoints and stops somewhere. Letting the user know will help users fix these kinds of issues and have a better debugging experience.
Examples of this include:
- enabling -gline-tables-only and being able to set file and line breakpoints and yet see no variables
- unable to open object file for DWARF in .o file debugging for darwin targets due to modification time mismatch or not being able to locate the N_OSO file.
This patch adds an new API to SBValueList:
lldb::SBError lldb::SBValueList::GetError();
object so that if you request a stack frame's variables using SBValueList SBFrame::GetVariables(...), you can get an error the describes why the variables were not available.
This patch adds the ability to get an error back when requesting variables from a lldb_private::StackFrame when calling GetVariableList.
It also now shows an error in response to "frame variable" if we have debug info and are unable to get varialbes due to an error as mentioned above:
(lldb) frame variable
error: "a.o" object from the "/tmp/libfoo.a" archive: either the .o file doesn't exist in the archive or the modification time (0x63111541) of the .o file doesn't match
Differential Revision: https://reviews.llvm.org/D133164
Complete support of the binary-addresses key in the qProcessInfo packet
in ProcessGDBRemote, for detecting if one of the binaries needs to be
handled by a Platform plugin, and can be used to set the Process'
DynamicLoader plugin and the Target's Platform plugin.
Implement this method in PlatformDarwinKernel to recognize a kernel
fileset at that address, find the actual kernel address in the
fileset, set DynamicLoaderDarwinKernel and PlatformDarwinKernel
in the Process/Target; register the kernel address with the dynamic
loader so it will be loaded later during attach.
This patch only addresses the live debug scenario with a gdb remote
serial protocol connection. I'll handle corefiles in a subsequent
patch that builds on this.
Differential Revision: https://reviews.llvm.org/D133534
rdar://98754861
Test for both IPv4 and IPv6 support to determine if either `127.0.0.1` or `[::1]` are appropriate IP addresses to attempt to connect to. In an IPv6-only environment, `127.0.0.1` is not available.
Using `localhost` is problematic because we might not be able to get the same port on each IP flavor, and later try to connect to the wrong thing.
Reviewed By: labath
Differential Revision: https://reviews.llvm.org/D133393
These tests started failing on green dragon after a configuration change that compiles tests using the just-built libcxx. We may need to force the system libcxx here, or change LLDB to import the std module from the just-built libcxx, too.
Move the broadcasting support from GDBRemoteCommunication
to GDBRemoteClientBase since this is where it is actually used. Remove
GDBRemoteCommunication and subclass constructor arguments left over
after Communication cleanup.
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.llvm.org/D133427
Uses our existing "error string" extension to provide a better
indication of why the launch failed (the client does not make use of the
error yet).
Also, fix the way we obtain the launch error message (make sure we read
the whole message, and skip trailing garbage), and reduce the size of
TestLldbGdbServer by splitting some tests into a separate file.
Differential Revision: https://reviews.llvm.org/D133352
The Read function could end up blocking if data (or EOF) arrived just as
it was about to start waiting for the events. This was only discovered
now, because we did not have unit tests for this functionality before.
We need to check for data *after* we start listening for incoming
events. There were no changes to the read thread code needed, as we
already use this pattern in SynchronizeWithReadThread, so I just updated
the comments to make it clear that it is used for reading as well.
Differential Revision: https://reviews.llvm.org/D133410
LLVM contains a helpful function for getting the size of a C-style
array: `llvm::array_lengthof`. This is useful prior to C++17, but not as
helpful for C++17 or later: `std::size` already has support for C-style
arrays.
Change call sites to use `std::size` instead.
Differential Revision: https://reviews.llvm.org/D133501
This commit improves upon cc0b5ebf7f, which added support for
specifying which libcxx to use when testing LLDB. That patch honored
requests by tests that had `USE_LIBCPP=1` defined in their makefiles.
Now, we also use a non-default libcxx if all conditions below are true:
1. The test is not explicitly requesting the use of libstdcpp
(USE_LIBSTDCPP=1).
2. The test is not explicitly requesting the use of the system's
library (USE_SYSTEM_STDLIB=1).
3. A path to libcxx was either provided by the user through CMake flags
or libcxx was built together with LLDB.
Condition (2) is new and introduced in this patch in order to support
tests that are either:
* Cross-platform (such as API/macosx/macCatalyst and
API/tools/lldb-server). The just-built libcxx is usually not built for
platforms other than the host's.
* Cross-language (such as API/lang/objc/exceptions). In this case, the
Objective C runtime throws an exceptions that always goes through the
system's libcxx, instead of the just built libcxx. Fixing this would
require either changing the install-name of the just built libcxx in Mac
systems, or tuning the DYLD_LIBRARY_PATH variable at runtime.
Some other tests exposes limitations of LLDB when running with a debug
standard library. TestDbgInfoContentForwardLists had an assertion
removed, as it was checking for buggy LLDB behavior (which now
crashes). TestFixIts had a variable renamed, as the old name clashes
with a standard library name when debug info is present. This is a known
issue: https://github.com/llvm/llvm-project/issues/34391.
For `TestSBModule`, the way the "main" module is found was changed to
look for the "a.out" module, instead of relying on the index being 0. In
some systems, the index 0 is dyld when a custom standard library is
used.
Differential Revision: https://reviews.llvm.org/D132940
Removed `GetParentDeclContextForSymbol` as this is not necesssary. We can get
the demangled names from CVSymbol and then using it to create tag decl or
namespace decl. This also fixed a bug when icf applied.
Differential Revision: https://reviews.llvm.org/D133243
For this patch, a simple search was performed for patterns where there are
two types (usually an LHS and an RHS) which are structurally the same, and there
is some result type which is resolved as either one of them (typically LHS for
consistency).
We change those cases to resolve as the common sugared type between those two,
utilizing the new infrastructure created for this purpose.
Depends on D111283
Signed-off-by: Matheus Izvekov <mizvekov@gmail.com>
Differential Revision: https://reviews.llvm.org/D111509
Split the read thread support from Communication into a dedicated
ThreadedCommunication subclass. The read thread support is used only
by a subset of Communication consumers, and it adds a lot of complexity
to the base class. Furthermore, having a dedicated subclass makes it
clear whether a particular consumer needs to account for the possibility
of read thread being running or not.
The modules currently calling `StartReadThread()` are updated to use
`ThreadedCommunication`. The remaining modules use the simplified
`Communication` class.
`SBCommunication` is changed to use `ThreadedCommunication` in order
to avoid changing the public API.
`CommunicationKDP` is updated in order to (hopefully) compile with
the new code. However, I do not have a Darwin box to test it, so I've
limited the changes to the bare minimum.
`GDBRemoteCommunication` is updated to become a `Broadcaster` directly.
Since it does not inherit from `ThreadedCommunication`, its event
support no longer collides with the one used for read thread and can
be implemented cleanly. The support for
`eBroadcastBitReadThreadDidExit` is removed from the code -- since
the read thread was not used, this event was never reported.
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.llvm.org/D133251
This will be used as a replacement for selecting over a pipe fd, which
does not work on windows. The posix implementation still uses a pipe
under the hood, while the windows version uses windows event handles.
The idea is that, instead of writing to a pipe, one just inserts a
callback, which does whatever you wanted to do after the bytes come out
the read end of the pipe.
Differential Revision: https://reviews.llvm.org/D131160
Fixes broken support for: `target.module[re.compile("libFoo")]`
There were two issues:
1. The type check was expecting `re.SRE_Pattern`
2. The expression to search the module path had a typo
In the first case, `re.SRE_Pattern` does not exist in Python 3, and is replaced
with `re.Pattern`.
While editing this code, I changed the type checks to us `isinstance`, which is
the conventional way of type checking.
From the docs on `type()`:
> The `isinstance()` built-in function is recommended for testing the type of an object, because it takes subclasses into account.
Differential Revision: https://reviews.llvm.org/D133130
TypeCategoryImpl has its own implementation of these, so it makes no
sense to have the same logic inlined in SBTypeCategory.
There are other methods in SBTypeCategory that are directly implemented
there, instead of delegating to TypeCategoryImpl (which IMO kinda
defeats the point of having an "opaque" member pointer in the SB type),
but they don't have equivalent implementations in TypeCategoryImpl, so
this patch only picks the low-hanging fruit for now.
This test, specifically `TwoSignalCallbacks`, can be a little bit flaky, failing in around 5/2000 runs.
POSIX says:
> If the value of pid causes sig to be generated for the sending process, and if sig is not blocked for the calling thread and if no other thread has sig unblocked or is waiting in a sigwait() function for sig, either sig or at least one pending unblocked signal shall be delivered to the sending thread before kill() returns.
The problem is that in test setup, we create a new thread with `std::async` and that is occasionally not cleaned up. This leaves that thread available to eat the signal we're polling for.
The need for this to be async does not apply anymore, so we can just make it synchronous.
This makes the test passes in 10000 runs.
Reviewed By: labath
Differential Revision: https://reviews.llvm.org/D133181
Change the behavior of the libc++ `unordered_map` synthetic provider to present
children as `std::pair` values, just like `std::map` does.
The synthetic provider for libc++ `std::unordered_map` has returned children
that expose a level of internal structure (over top of the key/value pair). For
example, given an unordered map initialized with `{{1,2}, {3, 4}}`, the output
is:
```
(std::unordered_map<int, int, std::hash<int>, std::equal_to<int>, std::allocator<std::pair<const int, int> > >) map = size=2 {
[0] = {
__cc = (first = 3, second = 4)
}
[1] = {
__cc = (first = 1, second = 2)
}
}
```
It's not ideal/necessary to have the numbered children embdedded in the `__cc`
field.
Note: the numbered children have type
`std::__hash_node<std::__hash_value_type<Key, T>, void *>::__node_value_type`,
and the `__cc` fields have type `std::__hash_value_type<Key, T>::value_type`.
Compare this output to `std::map`:
```
(std::map<int, int, std::less<int>, std::allocator<std::pair<const int, int> > >) map = size=2 {
[0] = (first = 1, second = 2)
[1] = (first = 3, second = 4)
```
Where the numbered children have type `std::pair<const Key, T>`.
This changes the behavior of the synthetic provider for `unordered_map` to also
present children as `pairs`, just like `std::map`.
It appears the synthetic provider implementation for `unordered_map` was meant
to provide this behavior, but was maybe incomplete (see
d22a94377f). It has both an `m_node_type` and an
`m_element_type`, but uses only the former. The latter is exactly the type
needed for the children pairs. With this existing code, it's not much of a
change to make this work.
Differential Revision: https://reviews.llvm.org/D117383
This patch fixes:
lldb/source/Plugins/Instruction/RISCV/EmulateInstructionRISCV.h:51:5:
error: default label in switch which covers all enumeration values
[-Werror,-Wcovered-switch-default]
Add:
- most of instructions from RVI base instructions set.
- some instruction decode tests from objdump.
Further work:
- implement riscv imac extension.
Reviewed By: DavidSpickett
Differential Revision: https://reviews.llvm.org/D132789
arm64e platforms.
On arm64e-capable Apple platforms, the system libraries are always
arm64e, but applications often are arm64. When a target is created
from file, LLDB recognizes it as an arm64 target, but debugserver will
still (technically correct) report the process as being arm64e. For
consistency, set the target to arm64 here.
rdar://92248684
Differential Revision: https://reviews.llvm.org/D133069
llvm::codeview::visitMemberRecordStream in CompleteTagDecl will call
GetOrCreateType create type if not seen before, which inserts new entries
into m_decl_to_status. This may invalidates status which is a reference to
std::pair::second from DenseMapIterator.
David Spickett