Add suport for MASK style watchpoints on AArch64 in debugserver
on Darwin systems, for watching power-of-2 sized memory ranges.
More work needed in lldb before this can be exposed to the user
(because they will often try watching memory ranges that are not
exactly power-of-2 in size/alignment) but this is the first part
of adding that capability.
Differential Revision: https://reviews.llvm.org/D149792
rdar://108233371
This patch add or removes XFAIL decorator from various tests which were marked
xfail for windows.
since 44363f2 various tests have started passing but introduced a couple of new failures.
Weight is in favor of new XPasses and I have removed XFail decorator from them. Also
some new tests have started failing for which we need to file separate bugs. I have
marked them xfail for now and will add the bug id after investigating the issue.
Differential Revision: https://reviews.llvm.org/D149235
Python 3 doesn't have a distinction between PyInt and PyLong, it's all
PyLong now.
This also fixes a bug in SetNumberFromObject. This used to crash LLDB:
```
lldb -o "script data=lldb.SBData(); data.SetDataFromUInt64Array([2**63])"
```
The problem happened in the PyInt path:
```
if (PyInt_Check(obj))
number = static_cast<T>(PyInt_AsLong(obj));
```
when obj doesn't fit in a signed long, `PyInt_AsLong` would fail with
"OverflowError: Python int too large to convert to C long".
The existing long path does the right thing, as it will call
`PyLong_AsUnsignedLongLong` for uint64_t.
Differential Revision: https://reviews.llvm.org/D146590
We used to make a dynamic value that "pretended to be its parent"
but that's hard for some of the more complex ValueObject types, and
it's better in this case just to return no dynamic value.
Differential Revision: https://reviews.llvm.org/D145629
Adding a new SBDebugger::SetDestroyCallback() API.
This API can be used by any client to query for statistics/metrics before
exiting debug sessions.
Differential Revision: https://reviews.llvm.org/D143520
This patch tries to address an interoperability issue when writing
python string into the process memory.
Since the python string is not null-terminated, it would still be
written to memory however, when trying to read it again with
`SBProcess::ReadCStringFromMemory`, the memory read would fail, since
the read string doens't contain a null-terminator, and therefore is not
a valid C string.
To address that, this patch extends the `SBProcess` SWIG interface to
expose a new `WriteMemoryAsCString` method that is only exposed to the
SWIG target language. That method checks that the buffer to write is
null-terminated and otherwise, it appends a null byte at the end of it.
Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
This patch adds the following methods:
* `GetType()`
* `GetWatchValueKind()`
* `GetWatchSpec()`
* `IsWatchingReads()`
* `IsWatchingWrites()`
These mostly expose methods that `lldb_private::Watchpoint` already
had. Tests are included that exercise these new methods.
The motivation for exposing these are as follows:
* `GetType()` - With this information and the address from a watchpoint
it is now possible to construct an SBValue from an SBWatchpoint.
Previously this wasn't possible. The included test case illustrates
doing this.
* `GetWatchValueKind()` - This allows the caller to determine whether the
watchpoint is a variable watchpoint or an expression watchpoint. A new
enum (`WatchpointValueKind`) has been introduced to represent the
return values. Unfortunately the name `WatchpointKind` was already
taken.
* `GetWatchSpec()` - This allows (at least for variable watchpoints)
to use a sensible name for SBValues created from an SBWatchpoint.
* `IsWatchingReads()` - This allow checking if a watchpoint is
monitoring read accesses.
* `IsWatchingWRites()` - This allow checking if a watchpoint is
monitoring write accesses.
rdar://105606978
Reviewers: jingham, mib, bulbazord, jasonmolenda, JDevlieghere
Differential Revision: https://reviews.llvm.org/D144937
initial stop. The code was using PrivateResume when it should have
used Resume.
This was allowing expression evaluation while the target was running,
and though that was caught a litle later on, we should never have gotten
that far. To make sure that this is caught immediately I made an error
SBValue when this happens, and test that we get this error.
Differential Revision: https://reviews.llvm.org/D144665
In json::Value, getAsInteger returns an optional<int64_t> and getAsNumber
returns an optional<double>. If a value is larger than what an int64_t
can hold but smaller than what a uint64_t can hold, the getAsInteger
function will fail but the getAsNumber will succeed. However, the value
shouldn't be interpreted as a double.
rdar://105556974
Differential Revision: https://reviews.llvm.org/D144238
The sanitizer bots are failing with this test; they
impose a maximum 0x10000000000 size on allocations, and
malloc on darwin will let me malloc that much. The
alternative to keep this would be to break it out into a
seperate test in TestProcessAIP and skip that if it's on
the sanitizer, but this is seeming too fragile IMO so I'm
punting it entirely.
To the Python bindings, add support for Python-like negative indexes.
While was using `script`, I tried to access a thread's bottom frame with
`thread.frame[-1]`, but that failed. This change updates the `__getitem__`
implementations to support negative indexes as one would expect in Python.
Differential Revision: https://reviews.llvm.org/D143282
I'm still getting linux CI bot failures for this test. It's not
critical, and it depends on a failure mode that is true on Darwin
but I was always gambling that it might fail in the same way on
other systems.
I hardcoded nearly a UINT64_MAX number in this test case,
and python is not able to convert it to a long on some
platforms. Use sys.maxsize instead; this also would have
failed if the testsuite was run on a 32-bit system.
Add a check for a null destination buffer in SBProcess::ReadMemory,
and return an error if that happens. If a Python SB API script
tries to allocate a huge amount of memory, the malloc done by the
intermediate layers will fail and will hand a null pointer to
ReadMemory. lldb will eventually crash trying to write in to that
buffer.
Also add a test that tries to allocate an impossibly large amount
of memory, and hopefully should result in a failed malloc and hitting
this error codepath.
Differential Revision: https://reviews.llvm.org/D143012
rdar://104846609
This patch introduces a new `GetScriptedImplementation` method to the
SBProcess class in the SBAPI. It will allow users of Scripted Processes to
fetch the scripted implementation object from to script interpreter to be
able to interact with it directly (without having to go through lldb).
This allows to user to perform action that are not specified in the
scripted process interface, like calling un-specified methods, but also
to enrich the implementation, by passing it complex objects.
Differential Revision: https://reviews.llvm.org/D143236
Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
`SBSection::GetSectionData` and `Section::GetSectionData` are
implemented differently, and the `SBSection` method doesn't handle
compressed sections correctly.
Differential Revision: https://reviews.llvm.org/D142672
In API tests, replace use of the `p` alias with the `expression` command.
To avoid conflating tests of the alias with tests of the expression command,
this patch canonicalizes to the use `expression`.
Differential Revision: https://reviews.llvm.org/D141539
Commit 92f0e4cca introduced test file with name TestChangeValue.py,
which leads to test failure because there already is a test files with the same name
In this commit a newly added file is renamed to fix this failure
`GetPropertyAtIndexAsArgs` returns true on success and false on failure. Right
now it returns the converted `size_t` returned from `GetArgs` which describes
the number of arguments in the argument list. So for empty argument lists
(`(size_t)0` -> `(bool)false`) this function always fails.
The only observable effect of this seems to be that empty arguments are never
propagated to the internal LaunchInfo for a process. This causes that once any
argument has been added to `target.run-args`, clearing `target.run-args` doesn't
have any effect.
Fixes issue #55568
Reviewed By: JDevlieghere, jingham
Differential Revision: https://reviews.llvm.org/D126057
Fix `fullpath` to not assume a `/` path separator. This was discovered when
D133130 failed on Windows. Use `os.path.join()` to fix the issue.
Reviewed By: mib
Differential Revision: https://reviews.llvm.org/D133366
This reverts commit 0205aa4a02 because it
breaks TestArray.py:
a->c = <parent failed to evaluate: parent is NULL>
I decided to revert instead of disable the test because it looks like a
legitimate issue with the patch.
This change fixes two issues in ValueObject::GetExpressionPath method:
1. Accessing members of struct references used to produce expression
paths such as "str.&str.member" (instead of the expected
"str.member"). This is fixed by assigning the flag tha the child
value is a dereference when calling Dereference() on references
and adjusting logic in expression path creation.
2. If the parent of member access is dereference, the produced
expression path was "*(ptr).member". This is incorrect, since it
dereferences the member instead of the pointer. This is fixed by
wrapping dereference expression into parenthesis, resulting with
"(*ptr).member".
Reviewed By: werat, clayborg
Differential Revision: https://reviews.llvm.org/D132734
This change fixes two issues in ValueObject::GetExpressionPath method:
1. Accessing members of struct references used to produce expression
paths such as "str.&str.member" (instead of the expected
"str.member"). This is fixed by assigning the flag tha the child
value is a dereference when calling Dereference() on references
and adjusting logic in expression path creation.
2. If the parent of member access is dereference, the produced
expression path was "*(ptr).member". This is incorrect, since it
dereferences the member instead of the pointer. This is fixed by
wrapping dereference expression into parenthesis, resulting with
"(*(ptr)).member".
Reviewed By: werat, clayborg
Differential Revision: https://reviews.llvm.org/D132734
With older DWARF versions we don't encode the enum's underlying
type in DWARF. In those cases LLDB sign-extends the bitfield as
a signed integer. Without the actual enum type being present in
DWARF there's not much we can do.
Differential Revision: https://reviews.llvm.org/D134734
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 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
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
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
Symbols that have the section index of SHN_ABS were previously creating extra top level sections that contained the value of the symbol as if the symbol's value was an address. As far as I can tell, these symbol's values are not addresses, even if they do have a size. To make matters worse, adding these extra sections can stop address lookups from succeeding if the symbol's value + size overlaps with an existing section as these sections get mapped into memory when the image is loaded by the dynamic loader. This can cause stack frames to appear empty as the address lookup fails completely.
This patch:
- doesn't create a section for any SHN_ABS symbols
- makes symbols that are absolute have values that are not addresses
- add accessors to SBSymbol to get the value and size of a symbol as raw integers. Prevoiusly there was no way to access a symbol's value from a SBSymbol because the only accessors were:
SBAddress SBSymbol::GetStartAddress();
SBAddress SBSymbol::GetEndAddress();
and these accessors would return an invalid SBAddress if the symbol's value wasn't an address
- Adds a test to ensure no ".absolute.<symbol-name>" sections are created
- Adds a test to test the new SBSymbol APIs
Differential Revision: https://reviews.llvm.org/D131705
Add a function to make it easier to debug a test failure caused by an
unexpected stop reason. This is similar to the assertState helper that
was added in ce825e4674.
Before:
self.assertEqual(stop_reason, lldb.eStopReasonInstrumentation)
AssertionError: 5 != 10
After:
self.assertStopReason(stop_reason, lldb.eStopReasonInstrumentation)
AssertionError: signal (5) != instrumentation (10)
Differential revision: https://reviews.llvm.org/D131083
D128477 adds the control flow kind for `Instruction` and displays this
in the `thread trace dump instruction -k` command.
This diff exposes the control flow kind via the new
`SBInstruction::GetControlFlowKind` method.
I've expanded `TestDisassembleRawData` to test this method, but please
let me know if there are any other unittests that should also be updated.
Test Plan:
`./bin/lldb-dotest -p TestDisassembleRawData`
Differential Revision: https://reviews.llvm.org/D131005
