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
Ensure that the variant returned by `member->getValue()` has a value and
is not `Empty`. Failure to do so will trigger an assertion failure in
`llvm::pdb::Variant::getBitWidth()`. This can occur when the `static`
member is a forward declaration.
Differential Revision: https://reviews.llvm.org/D146536
Reviewed By: sgraenitz
Prior to this the only check was that we did not print
this message when reading registers that should exist.
I thought there was an indentation bug here so I wrote a test
for it. There is not, but we could do with the coverage anyway.
Reviewed By: rupprecht
Differential Revision: https://reviews.llvm.org/D145940
Non-plugin lldb libraries should generally not be linking against lldb
plugin libraries. Enforce this in CMake.
Differential Revision: https://reviews.llvm.org/D146553
Move responsibility of providing the instance variable name (`this`, `self`) from
`TypeSystem` to `Language`.
`Language` the natural place for this, but also has downstream benefits. Some languages
have multiple `TypeSystem` implementations (ex Swift), and by placing this logic in the
`Language`, redundancy is avoided.
This change relies on the tests from D145348 and D146320.
Differential Revision: https://reviews.llvm.org/D146548
I came accross this, because a lot of regression tests were saying:
```
(lldb) p argc
error: expression failed to parse:
error: couldn't install checkers, unknown error
```
With this change, error messages provide more detail:
```
(lldb) p argc
error: expression failed to parse:
error: couldn't install checkers:
error: Couldn't lookup symbols:
__objc_load
```
I didn't find a case where `Diagnostics()` is not empty. Also it looks like this isn't covered in any test (yet).
Reviewed By: bulbazord, Michael137
Differential Revision: https://reviews.llvm.org/D146541
lldbUtility is not supposed to depend on anything else in lldb. Let's
enforce that constraint in CMake rather than hoping something doesn't
slip in under the radar.
Differential Revision: https://reviews.llvm.org/D146473
Change `dwim-print` to now disable persistent results by default, unless requested by
the user with the `--persistent-result` flag.
Ex:
```
(lldb) dwim-print 1 + 1
(int) 2
(lldb) dwim-print --persistent-result on -- 1 + 1
(int) $0 = 2
```
Users who wish to enable persistent results can make and use an alias that includes
`--persistent-result on`.
Updates: To recommit this, both TestPersistentResult.py and TestPAlias.py needed to be
updated, as well as the changes in D146230.
Differential Revision: https://reviews.llvm.org/D145609
Add an Objective-C++ specific test for direct ivar access. This adds to the existing C++ and ObjC tests, and tests against regression for future refactoring.
Differential Revision: https://reviews.llvm.org/D146320
../llvm-project/lldb/include/lldb/Interpreter/ScriptedProcessInterface.h:61:12:
warning: implicit conversion from 'unsigned long long' to 'size_t' (aka 'unsigned int')
changes value from 18446744073709551615 to 4294967295 [-Wconstant-conversion]
../llvm-project/lldb/source/Plugins/Process/scripted/ScriptedProcess.cpp:275:39:
warning: result of comparison of constant 18446744073709551615 with expression
of type 'size_t' (aka 'unsigned int') is always false [-Wtautological-constant-out-of-range-compare]
This happens because size_t on 32 bit is 32 bit, but LLDB_INVALID_OFFSET is
UINT64_MAX. Return lldb::offset_t instead, which is 64 bit everywhere.
DoWriteMemory still returns size_t but this is because every other
Process derived thing does that. As long as the failure check works I think
it should be fine.
Reviewed By: mib
Differential Revision: https://reviews.llvm.org/D146124
This adds a new macro to the UnixSignals subclasses, ADD_SIGCODE.
ADD_SIGCODE(4, ILL_ILLOPC, 1, "illegal opcode");
Adds a sigcode to signal 4. That code is ILL_ILLOPC and we expect
its value to be 1. When compiling on a system that matches the class
e.g. FreeBSD for FreeBSDSignals, the macro will check that that is true.
When you're not on FreeBSD we just use the number 1, and ILL_ILLOPC
won't be defined to anything because we don't include csignal.
Example error:
LinuxSignals.cpp:52:3: error: static_assert failed due to requirement
'ILL_COPROC == 9' "Value mismatch for signal code ILL_COPROC"
Reviewed By: arichardson
Differential Revision: https://reviews.llvm.org/D146222
Previously we only looked at the si_signo field, so you got:
```
(lldb) bt
* thread #1, name = 'a.out.mte', stop reason = signal SIGSEGV
* frame #0: 0x00000000004007f4
```
This patch adds si_code so we can show:
```
(lldb) bt
* thread #1, name = 'a.out.mte', stop reason = signal SIGSEGV: sync tag check fault
* frame #0: 0x00000000004007f4
```
The order of errno and code was incorrect in ElfLinuxSigInfo::Parse.
It was the order that a "swapped" siginfo arch would use, which for Linux,
is only MIPS. We removed MIPS Linux support some time ago.
See:
fe15c26ee2/include/uapi/asm-generic/siginfo.h (L121)
A test is added using memory tagging faults. Which were the original
motivation for the changes.
Reviewed By: JDevlieghere
Differential Revision: https://reviews.llvm.org/D146045
I didn't refactor the test that's failing on arm64 correctly so it
failed everywhere.
Looks like the step test passes on other aarch64 systems as well as
Darwin. Turn off the xfail and see how far that gets.
The high level goal of this change is to remove lldbTarget's dependency
on lldbPluginProcessUtility. The reason for this existing dependency is
so that we can create the appropriate UnixSignals object based on an
ArchSpec. Instead of using the ArchSpec, we can instead take advantage
of the Platform associated with the current Target.
This is accomplished by adding a new method to Platform,
CreateUnixSignals, which will create the correct UnixSignals object for
us. We then can use `Platform::GetUnixSignals` and rely on that to give
us the correct signals as needed.
Differential Revision: https://reviews.llvm.org/D146263
We need to step the watchpoint instruction in these cases, but the
when we queued the ThreadPlanStepOverWatchpoint to do this, we didn't
make it a Controlling plan. So if you are stepping, this plan returns as
though it were a utility plan, and the stepping plan keeps going.
This only partially fixes the problem on Darwin; there's another bug
with reporting a watchpoint when we're instruction single stepping over
an instruction that triggers a watchpoint. The kernel reports the
"single step completed" but not the watchpoint hit. So this commit
also refactors the test into a part that works (at least on Darwin) and
a part that still fails.
We may have to adjust the test result expectations for other systems after
this fix.
Differential Revision: https://reviews.llvm.org/D146337
The goal of this patch is to add the ability for the CMake configure to
fail when some optional test dependencies are not met. LLDB tries to be
flexible when test dependencies are not present but there are cases
where it would be useful to know that these dependencies are missing
before we run the test suite.
The intent here is to apply this setting on CI machines and make sure
that they have useful optional dependencies installed. We recently hit a
case where some CI machines were timing out while running the test suite
because a few tests were hanging. With this option, we'll be able to
know if the machine does not have psutil installed so we can install it
and avoid the timeout scenario altogether.
rdar://103194447
Differential Revision: https://reviews.llvm.org/D146335
By adding signal codes to UnixSignals and adding a new function
where you can get a string with optional address and bounds.
Added signal codes to the Linux, FreeBSD and NetBSD signal sets.
I've checked the numbers against the relevant sources.
Each signal code has a code number, description and printing options.
By default you just get the descripton, you can opt into adding either
a fault address or bounds information.
Bounds signals we'll use the description, unless we have the bounds
values in which case we say whether it is an upper or lower bound
issue.
GetCrashReasonString remains in CrashReason because we need it to
be compiled only for platforms with siginfo_t. Ideally it would
move into NativeProcessProtocol, but that is also used
by NativeRegisterContextWindows, where there would be no siginfo_t.
Reviewed By: JDevlieghere
Differential Revision: https://reviews.llvm.org/D146044
SymbolFile::ParseAllLanguages allows collecting the languages of the
extra compile units a SymbolFileDWARFDebugMap may have, which can't
be accessed otherwise. For every other symbol file type, it should
behave exactly the same as ParseLanguage.
rdar://97610458
Differential Revision: https://reviews.llvm.org/D146265
In Shell 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`.
See also D141539 which made the same change to API tests.
Differential Revision: https://reviews.llvm.org/D146230
LLDB uses `_up`, `_sp` and `_wp` suffixes for unique, shared and weak
pointers respectively. This can become confusing in combination with
watchpoints which are commonly abbreviated to `wp`. Update
CommandObjectWatchpoint to use `watch_sp` for all `WatchpointSP`
variables.
When setting a variable watchpoint, the watchpoint stores the variable
name in the watchpoint spec. For expression variables we should store
the expression in the watchpoint spec. This patch adds that
functionality.
rdar://106096860
Differential revision: https://reviews.llvm.org/D146262
This patch adds llvm::codeview::SourceLanguage entries, DWARF translations, and PDB source file extensions in LLVM and allow LLDB's PDB parsers to recognize them correctly.
The CV_CFL_LANG enum in the Visual Studio 2022 documentation https://learn.microsoft.com/en-us/visualstudio/debugger/debug-interface-access/cv-cfl-lang defines:
```
CV_CFL_OBJC = 0x11,
CV_CFL_OBJCXX = 0x12,
```
Since the initial commit in D24317, ObjC was emitted as C language and ObjC++ as Masm.
Reviewed By: DavidSpickett
Differential Revision: https://reviews.llvm.org/D146221
The old name of this function was confusing for me, when I started working on the PDB parser. The new name clearifies that the function adds file, line and column (typically referred as source info) and indicates that the information is stored in the provided decl parameter.
Reviewed By: DavidSpickett
Differential Revision: https://reviews.llvm.org/D146286
MemoryCache::Read is not resilient to partial reads when reading memory
chunks less than or equal in size to L2 cache lines. There have been
attempts in the past to fix this but nothing really solved the root of
the issue.
I first created a test exercising MemoryCache's implementation and
documenting how I believe MemoryCache::Read should behave. I then
rewrote the implementation of MemoryCache::Read as needed to make sure
that the different scenarios behaved correctly.
rdar://105407095
Differential Revision: https://reviews.llvm.org/D145624
PythonDataObjectsTest.TestExceptions started failing because the output
of the python traceback printers is now consistent between python and
cpython [1]. Work around the issue by supporting both variants.
Thanks to Ismail for identifying the root cause.
[1] https://github.com/python/cpython/issues/85203
Change `dwim-print` to now disable persistent results by default, unless requested by
the user with the `--persistent-result` flag.
Ex:
```
(lldb) dwim-print 1 + 1
(int) 2
(lldb) dwim-print --persistent-result on -- 1 + 1
(int) $0 = 2
```
Users who wish to enable persistent results can make and use an alias that includes
`--persistent-result on`.
Differential Revision: https://reviews.llvm.org/D145609
So that there is only one function that NativeThreads call,
which takes a siginfo. Everything else is an internal detail.
Reviewed By: labath, JDevlieghere
Differential Revision: https://reviews.llvm.org/D146043
The test was relying on the json module getting imported transitively by
one of its imported modules. Make this less brittle by importing it
explicitly.
