On AArch64 systems, we may have different page table setups for
low memory and high memory, and therefore a different number of
bits used for addressing depending on which half of memory the
address is in.
This patch extends the qHostInfo and LC_NOTE "addrable bits" so
that it can specify the number of addressing bits in high memory
and in low memory separately. It builds on the patch I added in
https://reviews.llvm.org/D151292 where Process tracks the separate
address masks, and there is a user setting to set them manually.
Differential Revision: https://reviews.llvm.org/D157667
rdar://113225907
This patch fixes warnings like:
lldb/source/Core/ModuleList.cpp:1086:3: error: 'scoped_lock' may not
intend to support class template argument deduction
[-Werror,-Wctad-maybe-unsupported]
These functions have been NO-OPs since 2014 (44d937820b). Remove them
and deprecate the corresponding functions in SBDebugger.
Differential revision: https://reviews.llvm.org/D158000
This reverts commit 4e3b89483a, with
fixes for places I'd missed updating in lld and lldb. I've also
renamed OptionVisibility::Default to "DefaultVis" to avoid ambiguity
since the undecorated name has to be available anywhere Options.inc is
included.
Original message follows:
This splits OptTable's "Flags" field into "Flags" and "Visibility",
updates the places where we instantiate Option tables, and adds
variants of the OptTable APIs that use Visibility mask instead of
Include/Exclude flags.
We need to do this to clean up a bunch of complexity in the clang
driver's option handling - there's a whole slew of flags like
CoreOption, NoDriverOption, and FlangOnlyOption there today to try to
handle all of the permutations of flags that the various drivers need,
but it really doesn't scale well, as can be seen by things like the
somewhat recently introduced CLDXCOption.
Instead, we'll provide an additive model for visibility that's
separate from the other flags. For things like "HelpHidden", which is
used as a "subtractive" modifier for option visibility, we leave that
in "Flags" and handle it as a special case.
Note that we don't actually update the users of the Include/Exclude
APIs here or change the flags that exist in clang at all - that will
come in a follow up that refactors clang's Options.td to use the
increased flexibility this change allows.
Differential Revision: https://reviews.llvm.org/D157149
My primary motivation here is actually to change something in
UnixSignals, but this change is a necesary precondition.
I've also updated the documentation and rewritten the log statements to
use `formatv` instead of `printf` (printf-style formatting and
llvm::StringRef don't mix well).
Differential Revision: https://reviews.llvm.org/D157662
As stated on Discourse*, these methods have been deprecated. I am
removing their implementation. They will now do nothing and return a
value indicating failure (where appropriate).
Due to the LLDB project's commitment to ABI stability at the SB API
layer, we cannot remove these symbols completely.
Discourse link: https://discourse.llvm.org/t/do-you-use-the-threading-functionality-in-sbhostos/71973
These were useful primarily for the Python 2 to 3 transition. Python 2
is no longer supported so these are no longer necessary.
Differential Revision: https://reviews.llvm.org/D157759
Since the info in MCInstrDesc is based on opcodes only, it is often quite
inaccurate. The MCInstrAnalysis has been added so that targets can provide
accurate info, which is based on registers used by the instruction, through
the own versions of MCInstrDesc functions.
The RISCVMCInstrAnalysis, which needs to refine several MCInstrDesc methods,
is a good example for this.
Given the llvm-objdump also uses MCInstrAnalysis, I think this change is in
the right direction.
The default implementation of MCInstrAnalysis methods forward the query to
MCInstrDesc functions. Hence, no functional change is intended/expected.
To avoid bloating up MCInstrAnalysis, only the methods provided by it and
the ones used by disassembler plugin are changed to use MCInstrAnalysis when
available.
Though I am not sure if it will be useful, making MCInstrAnalysis available
in the disassembler plugin would allow enabling symbolize operands (D84191)
feature in lldb's disassembler as well.
Reviewed By: jasonmolenda
Differential Revision: https://reviews.llvm.org/D156086
This patch skips images with an empty path or a 0 UUID from loading as a
SymbolFileJSON.
rdar://112107986
Differential Revision: https://reviews.llvm.org/D157137
Signed-off-by: Med Ismail Bennani <ismail@bennani.ma>
Prior to this patch, when a user loaded multiple crash report in lldb,
they could get in a situation where all the targets would keep the same
architecture and executable path as the first one that we've created.
The reason behind this was that even if we created a new CrashLog
object, which is derived from a Symbolicator class that has a newly
constructoted image list as a default argument, because that default
argument is only created once when the function is defined, every CrashLog
object would share the same list.
That will cause use to append newly parsed images to the same
Symbolicator image list accross multiple CrashLog objects.
To address this, this patch changes the default argument value for the
image parameter to `None` and only initialize it as an empty list when
no argument was passed.
This also removes the image list stored in each CrashLog parsers since
they shouldn't have any state and should be re-usable. So now, the only
source of truth is stored in the CrashLog object.
rdar://84984949
Differential Revision: https://reviews.llvm.org/D157044
Signed-off-by: Med Ismail Bennani <ismail@bennani.ma>
This patch changes the parsing logic for the legacy crash report format
to avoid interrupting the parsing if there are new lines in the middle
of a section.
To do, the parser starts to skip all consecutive empty lines. If the
number of lines skipped is greater than 1, the parser considers that it
reached a new setion of the report and should reset the parsing mode to
back to normal.
Otherwise, it tries to parse the next line in the current parsing mode.
If it succeeds, the parser will also skip that line since it has already
been parsed and continue the parsing.
rdar://107022595
Differential Revision: https://reviews.llvm.org/D157043
Signed-off-by: Med Ismail Bennani <ismail@bennani.ma>
This patch changes the way we dump the registers from the legacy
crashlog command to make sure that the ordering matches the one from lldb.
rdar://109172073
Differential Revision: https://reviews.llvm.org/D156919
Signed-off-by: Med Ismail Bennani <ismail@bennani.ma>
Make SBTarget::AddModule possibly call out to an external program to
find the binary by UUID if it can't be found more easily, the same
way `target modules add -u ...` works from the commandline.
If the Target does not have an architecture set yet, use the
Module's Arch to initialize it. Allows an API writer to create
a target with no arch, and inherit it from the first binary they
load with AddModules.
Differential Revision: https://reviews.llvm.org/D157659
rdar://113657555
On the Swift forums, people are disabling SIP in order to debug process
that are missing the get-task-allow entitlement. Improve the error to
give developers a hint at the potential issues.
rdar://113704200
Differential revision: https://reviews.llvm.org/D157640
/data/home/jiefu/llvm-project/lldb/source/Host/common/File.cpp:251:3: error: 'scoped_lock' may not intend to support class template argument deduction [-Werror,-Wctad-maybe-unsupported]
std::scoped_lock lock(m_descriptor_mutex, m_stream_mutex);
^
/opt/rh/gcc-toolset-12/root/usr/lib/gcc/x86_64-redhat-linux/12/../../../../include/c++/12/mutex:692:11: note: add a deduction guide to suppress this warning
class scoped_lock
^
/data/home/jiefu/llvm-project/lldb/source/Host/common/File.cpp:316:3: error: 'scoped_lock' may not intend to support class template argument deduction [-Werror,-Wctad-maybe-unsupported]
std::scoped_lock lock(m_descriptor_mutex, m_stream_mutex);
^
/opt/rh/gcc-toolset-12/root/usr/lib/gcc/x86_64-redhat-linux/12/../../../../include/c++/12/mutex:692:11: note: add a deduction guide to suppress this warning
class scoped_lock
^
2 errors generated.
(motivated by test failures after D157058)
With D157058 the base template for `std::char_traits` was removed from
libc++. Quoting the release notes:
```
The base template for ``std::char_traits`` has been removed. If you are using
``std::char_traits`` with types other than ``char``, ``wchar_t``, ``char8_t``,
``char16_t``, ``char32_t`` or a custom character type for which you
specialized ``std::char_traits``, your code will no longer work.
```
This patch simply removes all such instantiations to make sure the
tests that run against the latest libc++ version pass.
One could try testing the existence of this base template from within
the test source files but this doesn't seem like something we want
support.
Differential Revision: https://reviews.llvm.org/D157636
Just about every file in the lldb project is built with C++ enabled.
Unless I've missed something, these macro guards don't really accomplish
very much.
Differential Revision: https://reviews.llvm.org/D157538
TSan reports the following data race:
Write of size 4 at 0x000109e0b160 by thread T2 (...):
#0 lldb_private::NativeFile::Close() File.cpp:329
#1 lldb_private::ConnectionFileDescriptor::Disconnect(...) ConnectionFileDescriptorPosix.cpp:232
#2 lldb_private::Communication::Disconnect(...) Communication.cpp:61
#3 lldb_private::process_gdb_remote::ProcessGDBRemote::DidExit() ProcessGDBRemote.cpp:1164
#4 lldb_private::Process::SetExitStatus(...) Process.cpp:1097
#5 lldb_private::process_gdb_remote::ProcessGDBRemote::MonitorDebugserverProcess(...) ProcessGDBRemote.cpp:3387
Previous read of size 4 at 0x000109e0b160 by main thread (...):
#0 lldb_private::NativeFile::IsValid() const File.h:393
#1 lldb_private::ConnectionFileDescriptor::IsConnected() const ConnectionFileDescriptorPosix.cpp:121
#2 lldb_private::Communication::IsConnected() const Communication.cpp:79
#3 lldb_private::process_gdb_remote::GDBRemoteCommunication::WaitForPacketNoLock(...) GDBRemoteCommunication.cpp:256
#4 lldb_private::process_gdb_remote::GDBRemoteCommunication::WaitForPacketNoLock(...) GDBRemoteCommunication.cpp:244
#5 lldb_private::process_gdb_remote::GDBRemoteClientBase::SendPacketAndWaitForResponseNoLock(...) GDBRemoteClientBase.cpp:246
I originally tried fixing the problem at the ConnectionFileDescriptor
level, but that operates on an IOObject which can have different thread
safety guarantees depending on its implementation.
For this particular issue, the problem is specific to NativeFile.
NativeFile can hold a file descriptor and/or a file stream. Throughout
its implementation, it checks if the descriptor or stream is valid and
do some operation on it if it is. While that works in a single threaded
environment, nothing prevents another thread from modifying the
descriptor or stream between the IsValid check and when it's actually
being used.
This patch prevents such issues by returning a ValueGuard RAII object.
As long as the object is in scope, the value is guaranteed by a lock.
Differential revision: https://reviews.llvm.org/D157347
Since https://reviews.llvm.org/D157058 in libc++,
the base template for char_traits has been removed - it is only
provided for char, wchar_t, char8_t, char16_t and char32_t.
(Thus, to use basic_string with a type other than those, we'd need
to supply suitable traits ourselves.)
For this particular use, a vector works just as well as basic_string.
Differential Revision: https://reviews.llvm.org/D157589
StreamFile subclasses Stream (from lldbUtility) and is backed by a File
(from lldbHost). It does not depend on anything from lldbCore or any of its
sibling libraries, so I think it makes sense for this to live in
lldbHost instead.
Differential Revision: https://reviews.llvm.org/D157460
TSan reports the following race:
Write of size 8 at 0x000107707ee8 by main thread:
#0 lldb_private::ThreadedCommunication::StartReadThread(...) ThreadedCommunication.cpp:175
#1 lldb_private::Process::SetSTDIOFileDescriptor(...) Process.cpp:4533
#2 lldb_private::Platform::DebugProcess(...) Platform.cpp:1121
#3 lldb_private::PlatformDarwin::DebugProcess(...) PlatformDarwin.cpp:711
#4 lldb_private::Target::Launch(...) Target.cpp:3235
#5 CommandObjectProcessLaunch::DoExecute(...) CommandObjectProcess.cpp:256
#6 lldb_private::CommandObjectParsed::Execute(...) CommandObject.cpp:751
#7 lldb_private::CommandInterpreter::HandleCommand(...) CommandInterpreter.cpp:2054
Previous read of size 8 at 0x000107707ee8 by thread T5:
#0 lldb_private::HostThread::IsJoinable(...) const HostThread.cpp:30
#1 lldb_private::ThreadedCommunication::StopReadThread(...) ThreadedCommunication.cpp:192
#2 lldb_private::Process::ShouldBroadcastEvent(...) Process.cpp:3420
#3 lldb_private::Process::HandlePrivateEvent(...) Process.cpp:3728
#4 lldb_private::Process::RunPrivateStateThread(...) Process.cpp:3914
#5 std::__1::__function::__func<lldb_private::Process::StartPrivateStateThread(...) function.h:356
#6 lldb_private::HostNativeThreadBase::ThreadCreateTrampoline(...) HostNativeThreadBase.cpp:62
#7 lldb_private::HostThreadMacOSX::ThreadCreateTrampoline(...) HostThreadMacOSX.mm:18
The problem is the lack of synchronization between starting and stopping
the read thread. This patch fixes that by protecting those operations
with a mutex.
Differential revision: https://reviews.llvm.org/D157361
When lldb starts a kernel debug session, it has the UUID of the
kernel binary. lldb will try three different methods to find a
binary and symbol file for this UUID. Currently it calls out to
Symbols::DownloadObjectAndSymbolFile() first, which may be the
slowest method when a DBGShellCommand can find the UUID on a
network filesystem or downloaded from a server.
This patch tries the local searches first, then falls back to that
method.
Differential Revision: https://reviews.llvm.org/D157165
The DebugSymbols DBGShellsCommand, which can find the symbols
for binaries, has a mechanism to return error messages when
it cannot find a symbol file. Those errors were not printed
to the user for several corefile use case scenarios; this
patch fixes that.
Also add dyld/process logging for the LC_NOTE metadata parsers
in ObjectFileMachO, to help in seeing what lldb is basing its
searches on.
Differential Revision: https://reviews.llvm.org/D157160
Mach-O corefiles have several possible types of metadata for the
binaries that were running when the corefile was written.
ProcessMachCore will try to find these binaries, and load them.
When we have a hint, but could not find the binary, this change
makes ProcessMachCore not fall back to scanning the corefile looking
for ANY binary that it could load. We sometimes have multiple binaries
present in the memory in a corefile, but only the correct binary
should be loaded, the others are data.
Differential Revision: https://reviews.llvm.org/D157168
rdar://112602508
TSan reports the following data race:
Write of size 4 at 0x000109e0b160 by thread T2 (mutexes: write M0, write M1):
#0 NativeFile::Close() File.cpp:329
#1 ConnectionFileDescriptor::Disconnect(lldb_private::Status*) ConnectionFileDescriptorPosix.cpp:232
#2 Communication::Disconnect(lldb_private::Status*) Communication.cpp:61
#3 process_gdb_remote::ProcessGDBRemote::DidExit() ProcessGDBRemote.cpp:1164
#4 Process::SetExitStatus(int, char const*) Process.cpp:1097
#5 process_gdb_remote::ProcessGDBRemote::MonitorDebugserverProcess(...) ProcessGDBRemote.cpp:3387
Previous read of size 4 at 0x000109e0b160 by main thread (mutexes: write M2):
#0 NativeFile::IsValid() const File.h:393
#1 ConnectionFileDescriptor::IsConnected() const ConnectionFileDescriptorPosix.cpp:121
#2 Communication::IsConnected() const Communication.cpp:79
#3 process_gdb_remote::GDBRemoteCommunication::WaitForPacketNoLock(...) GDBRemoteCommunication.cpp:256
#4 process_gdb_remote::GDBRemoteCommunication::WaitForPacketNoLock(...l) GDBRemoteCommunication.cpp:244
#5 process_gdb_remote::GDBRemoteClientBase::SendPacketAndWaitForResponseNoLock(llvm::StringRef, StringExtractorGDBRemote&) GDBRemoteClientBase.cpp:246
The problem is that in WaitForPacketNoLock's run loop, it checks that
the connection is still connected. This races with the
ConnectionFileDescriptor disconnecting. Most (but not all) access to the
IOObject in ConnectionFileDescriptorPosix is already gated by the mutex.
This patch just protects IsConnected in the same way.
Differential revision: https://reviews.llvm.org/D157347
DynamicLoader::LoadBinaryWithUUIDAndAddress can create a Module based
on the binary image in memory, which in some cases contains symbol
names and can be genuinely useful. If we don't have a filename, it
creates a name in the form `memory-image-0x...` with the header address.
In practice, this is most useful with Darwin userland corefiles
where the binary was stored in the corefile in whole, and we can't
find a binary with the matching UUID. Using the binary out of
the corefile memory in this case works well.
But in other cases, akin to firmware debugging, we merely end up
with an oddly named binary image and no symbols.
Add a flag to control whether we will create these memory images
and add them to the Target or not; only set it to true when working
with a userland Mach-O image with the "all image infos" LC_NOTE for
a userland corefile.
Differential Revision: https://reviews.llvm.org/D157167
Set the halt_on_error runtime flag to make TSan errors fatal when
running the test suite. For the API tests the environment variables are
set conditionally on whether the TSan is enabled. The Shell and Unit
tests don't have that logic but setting the environment variable is
harmless. For consistency, I've also mirrored the ASAN option
(detect_stack_use_after_return=1) for the Shell tests.
Differential revision: https://reviews.llvm.org/D157152
This has failed once in a while on our Windows on Arm bot:
https://lab.llvm.org/buildbot/#/builders/219/builds/4688
Traceback (most recent call last):
File "C:\Users\tcwg\llvm-worker\lldb-aarch64-windows\...
self.assertGreaterEqual(duration_sec, 1)
AssertionError: 0.9907491207122803 not greater than or equal to 1
We're not here to check that Python/the C++ lib/the OS implemented
timers correctly, so accept anything 0.95 or greater.
In file included from /data/workspace/llvm-project/lldb/unittests/ObjectFile/PECOFF/TestSectionSize.cpp:10:
/data/workspace/llvm-project/third-party/unittest/googletest/include/gtest/gtest.h:1620:28: error: comparison of integers of different signs: 'c
onst unsigned long' and 'const int' [-Werror,-Wsign-compare]
GTEST_IMPL_CMP_HELPER_(NE, !=);
~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~
/data/llvm-project/lldb/source/Interpreter/OptionValue.cpp:28:3: error: 'scoped_lock' may not intend to support class template argument deduction [-Werror,-Wctad-maybe-unsupported]
std::scoped_lock lock(m_mutex, other.m_mutex);
^
/opt/rh/gcc-toolset-12/root/usr/lib/gcc/x86_64-redhat-linux/12/../../../../include/c++/12/mutex:692:11: note: add a deduction guide to suppress this warning
class scoped_lock
^
1 error generated.
/data/llvm-project/lldb/source/Target/ThreadList.cpp:739:5: error: 'scoped_lock' may not intend to support class template argument deduction [-Werror,-Wctad-maybe-unsupported]
std::scoped_lock guard(GetMutex(), rhs.GetMutex());
^
/opt/rh/gcc-toolset-12/root/usr/lib/gcc/x86_64-redhat-linux/12/../../../../include/c++/12/mutex:692:11: note: add a deduction guide to suppress this warning
class scoped_lock
^
1 error generated.
ThreadList::Update is being caught by thread sanitizer. There's even a
comment on the function that both mutexes should be lock (even though
only the "this" mutex was actually being locked). Fix this by locking
both mutexes.
Differential Revision: https://reviews.llvm.org/D157153
Thread sanitizer is catching data races in OptionValue, protect accesses
to OptionValue with a mutex.
Differential Revision: https://reviews.llvm.org/D157041
SWIG 4 was released in 2019 and has been the de-facto standard for a
while now. All bots are running SWIG 4.0 or later.
This was motivated by #64279 which discovered that 662548c broke the
LLDB build with SWIG 3 on Windows.
Differential revision: https://reviews.llvm.org/D156804
All command-line tools using `llvm::opt` create an enum of option IDs and a table of `OptTable::Info` object. Most of the tools use the same ID (`OPT_##ID`), kind (`Option::KIND##Class`), group ID (`OPT_##GROUP`) and alias ID (`OPT_##ALIAS`). This patch extracts that common code into canonical macros. This results in fewer changes when tweaking the `OPTION` macros emitted by the TableGen backend.
Reviewed By: MaskRay
Differential Revision: https://reviews.llvm.org/D157028
There can be zero padding bytes at a section end for file alignment in
PECOFF. Exclude those padding bytes when reading the section data.
Differential Revision: https://reviews.llvm.org/D157059
It isn't useful for users to see "<unknown>" as a stack trace when lldb fails to symbolicate a stack frame. I've replaced "<unknown>" with the value of the program counter instead.
Test Plan:
To test this, I opened a target that lldb fails to symbolicate in
VSCode, and observed in the CALL STACK section that instead of being
shown as "<unknown>", those stack frames are represented by their
program counters.
I added a new test case, `TestVSCode_stackTraceMissingFunctionName` that
exercises this feature.
I also ran `lldb-dotest -p TestVSCode` and saw that the tests passed.
Differential Revision: https://reviews.llvm.org/D156732
Summary:
In cases where the PC has no function name, lldb-vscode crashes.
`lldb::SBFrame::GetDisplayFunctionName()` returns a `nullptr`, and when we
attempt to construct an `std::string`, it raises an exception.
Test plan:
This can be observed with creating a test file (credit to @clayborg for
the example):
```
int main() {
typedef void (*FooCallback)();
FooCallback foo_callback = (FooCallback)0;
foo_callback(); // Crash at zero!
return 0;
}
```
and attempting to debug the file through VSCode.
I add a test case in D156732 which should cover this.
Differential Revision: https://reviews.llvm.org/D156970
This makes anlysing test failures much more easy.
For SendJSON this is simple, just use llvm::format instead.
For GetNextObject/ReadJSON it's a bit more tricky.
* Print the "Content-Length:" line in ReadJSON, but not the json.
* Back in GetNextObject, if the JSON doesn't parse, it'll be
printed as a normal string along with an error message.
* If we didn't error before, we have a JSON value so we pretty print it.
* Finally, if it isn't an object we'll log an error for that,
not including the JSON.
Before:
```
<--
Content-Length: 81
{"command":"disconnect","request_seq":5,"seq":0,"success":true,"type":"response"}
```
After:
```
<--
Content-Length: 81
{
"command": "disconnect",
"request_seq": 5,
"seq": 0,
"success": true,
"type": "response"
}
```
There appear to be some responses that include strings that are themselves JSON,
and this won't pretty print those but I think it's still worth doing.
Reviewed By: wallace
Differential Revision: https://reviews.llvm.org/D156979
Previously lldb was storing them but not restoring them. Meaning that this function:
```
void expr(uint64_t value) {
__asm__ volatile("msr tpidr_el0, %0" ::"r"(value));
}
```
When run from lldb:
```
(lldb) expression expr()
```
Would leave tpidr as `value` instead of the original value of the register.
A check for this scenario has been added to TestAArch64LinuxTLSRegisters.py,
which covers tpidr and the SME excluisve tpidr2 register when it's present.
Reviewed By: omjavaid
Differential Revision: https://reviews.llvm.org/D156512
7e229217f4 did live processes, this does
core files. Pretty simple, there is an NT_ARM_TLS note that contains
at least tpidr, and on systems with the Scalable Matrix Extension (SME), tpidr2
as well.
tpidr2 will be handled in future patches for SME support.
This NT_ARM_TLS note has always been present but it seems convenient to
handle it as "optional" inside of LLDB. We'll probably want the flexibility
when supporting tpidr2.
Normally the C library would set tpidr but all our test sources build
without it. So I've updated the neon test program to write to tpidr
and regenerated the corefile.
I've removed the LLDB_PTRACE_NT_ARM_TLS that was unused, we get
what we need from llvm's defs instead.
Reviewed By: omjavaid
Differential Revision: https://reviews.llvm.org/D156118
Lots of users use "po" as their default print command. If the type
doesn't implement the description function the output is often not what
the user wants. Print a hint telling the user that they might prefer
using "p" instead.
Differential Revision: https://reviews.llvm.org/D153489
Check the interrupt flag while interpreting IR expressions and allow the
user to interrupt them.
Differential revision: https://reviews.llvm.org/D156822
There were some checks removed previously in
bc196970b5.
However, all these SPIs are actually defined in macOS 12 and onward, not
macOSX 10.12 as the previous commit would suggest. As a result, if you
have access to these SPIs lldb will fail to compile correctly.
Instead of adding back the __builtin_availability checks, it seems
easier just to check the minimum deployment target with Availability
macros.
Differential Revision: https://reviews.llvm.org/D156838
These tests started failing on the public build-bots recently
with following error:
```
AssertionError: 'error: Couldn't lookup symbols:
__ZNSt3__122__libcpp_verbose_abortEPKcz
' is not success
```
We've seen this previously when the SDKs we used to compile the
`std` module differ from the test program.
(see D146714, rdar://107052293, D139361, rdar://102427461)
Skip these tests on older MacOS versions for now.
This is possibly related to the recent `std` module changes in D144322.
rdar://113227172
Differential Revision: https://reviews.llvm.org/D156827
The previous patch D156367 introduced a test debugging thin archive with one of the linked object file missing. It actually failed on green dragon build bots. I put up a speculative fix (4520cc066b) that only fixed the symptom of it.
The actual root cause was that the timestamps were set to 0 when creating the thin archive
Makefile command
```
llvm-ar -rcsDT libfoo-thin.a a.o b.o
```
Where the flag "[D] - use zero for timestamps and uids/gids (default)" according to the llvm-ar help
Use "[U] - use actual timestamps and uids/gids" fixed the timestamp
Now the test is actually getting error from missing object file linked to the thin archive instead of the mismatched timestamp.
This means removing one of the object file a.o should only result in failure breaking at `a()`; breaking at `b()` should work just fine.
Test Plan:
All 4 test cases passed
```
▶ ./bin/llvm-lit -vv ../llvm-project/lldb/test/API/functionalities/archives/TestBSDArchives.py
llvm-lit: /Users/wanyi/local/llvm-project/lldb/test/API/lit.cfg.py:173: warning: Could not set a default per-test timeout. Requires the Python psutil module but it could not be found. Try installing it via pip or via your operating system's package manager.
-- Testing: 1 tests, 1 workers --
PASS: lldb-api :: functionalities/archives/TestBSDArchives.py (1 of 1)
Testing Time: 8.07s
Passed: 1
1 warning(s) in tests
```
Differential Revision: https://reviews.llvm.org/D156564
At the moment the IRInterpreter will stop interpreting an expression
after a hardcoded 4096 instructions. After it reaches the limit it will
stop interpreting and leave the process in whatever state it was when
the timeout was reached.
This patch changes the instruction limit to a timeout and uses the
user-specified expression timeout value for this. The main motivation is
to allow users on targets where we can't use the JIT to run more
complicated expressions if they really want to (which they can do now by
just increasing the timeout).
The time-based approach also seems much more meaningful than the
arbitrary (and very low) instruction limit. 4096 instructions can be
interpreted in a few microseconds on some setups but might take much
longer if we have a slow connection to the target. I don't think any
user actually cares about the number of instructions that are executed
but only about the time they are willing to wait for a result.
Based off an original patch by Raphael Isemann.
Differential revision: https://reviews.llvm.org/D102762
In a809720102 I refactored some logic to
deal with the clang resource directory in standalone LLDB builds.
However, this logic escaped me because it only runs when you do not
build LLDB.framework.
Differential Revision: https://reviews.llvm.org/D156763
This commit does a few related things:
- Removes unused function `uuid_is_null`
- Removes unneeded includes of UuidCompatibility.h
- Renames UuidCompatibility to AppleUuidCompatibility and adds a comment
to clarify intent of header.
- Moves AppleUuidCompatibility to the include directory
Differential Revision: https://reviews.llvm.org/D156562
Improve memory usage by reducing the lifetime of CTF types. Once a CTF
type has been converted to a (complete) LLDB type, there's no need to
keep it in memory anymore. For most types, we can free them right after
creating the corresponding LLDB types. The only exception is record
types, which are only completed lazily.
Differential revision: https://reviews.llvm.org/D156606
This was probably the only really useful radar in our source code. It's
a request to be able to tell if __LINKEDIT has been mapped or not. I've
left a comment in the radar that we should update the corresponding code
if and when such an ability becomes available.
The existing comment already explains what the problem is. The radar
tracks caching negative lookups in xcrun. Having a backlink is handy,
but it's not necessary as the radar references the LLDB workaround.
Furthermore, we have other places in LLDB that work around xcrun not
caching negative that should potentially be reconsidered at that time.
This replaces two radar links with improved comments explaining the
underlying issues.
- The first issue is working around a compiler bug that was fixed in
f454dfb6b5.
- The second issue is an invariant that doesn't actually hold. The
latter was marked as FIXME but there was nothing in the radar about a
possible alternative solution.
Both radars were closed.
This replaces the radar link with a comment explaining the underlying
problem, which is that when the (dynamic) type of an object changes, so
does their synthetic filter of choice, which requires us to regenerate
the filter.
The comment after the radar link already explains the issue. There's no
additional information in the radar and has been marked as closed by the
corresponding code change. This commit removes the link and reflows the
comment.
The code was commented out because it would trigger an assert in the
source manager. I can no longer reproduce the assert and none of the
ASan tests are failing with the code re-enabled.
The comment and radar referenced PyThreadState_Get which is no longer
used there and instead has been replaced to a call to
PyThreadState_GetDict which has different semantics. Unlike
PyThreadState_Get, it can return NULL and it is okay to call this
function when no current thread state is available.
Support recursive record types in CTF, for example a struct that
contains a pointer to itself:
struct S {
struct S *n;
};
We are now more lazy when creating LLDB types. When encountering a
record type (struct or union) we create a forward declaration and only
complete it when requested.
Differential revision: https://reviews.llvm.org/D156498
Fix parsing of large structs. If the size of a struct exceeds a certain
threshold, the offset is encoded using two 32-bit integers instead of
one.
Differential revision: https://reviews.llvm.org/D156490
On Apple platforms when debugging with libBacktraceRecording.dylib backtraces are stored as part of the thread stack. This change includes support for displaying the back traces when they are present in the stack trace.
To use this on macOS a binary needs to be run with the following environment variables configured:
DYLD_LIBRARY_PATH=/usr/lib/system/introspection
DYLD_INSERT_LIBRARIES=/Applications/Xcode.app/Contents/Developer/usr/lib/libBacktraceRecording.dylib
{F28473587}
Reviewed By: wallace
Differential Revision: https://reviews.llvm.org/D156465
Separate parsing CTF and creating LLDB types. This is a prerequisite to
parsing forward references and recursive types.
Differential revision: https://reviews.llvm.org/D156447
Recently we've observed lldb crashes caused by missing object file linked to a thin archive (.a) files. The crash is due to a missing NULL check in the code when looking for child object file referred by the thin archive. Malformed archive file should not crash LLDB. Instead, it should report the error and continue.
New error message will look like the following
```
error: libfoo.a(__objects__/foo/barAppDelegate.mm.o) failed to load objfile for path/to/libfoo.a.
Debugging will be degraded for this module.
```
Test Plan:
llvm-lit test
```
./bin/llvm-lit -sv ../llvm-project/lldb/test/API/functionalities/archives/TestBSDArchives.py
```
Test without code change will error out with LLDB crash
```
--
Command Output (stderr):
--
PASS: LLDB (~/llvm-upstream/Debug/bin/clang-arm64) :: test (TestBSDArchives.BSDArchivesTestCase)
PASS: LLDB (~/llvm-upstream/Debug/bin/clang-arm64) :: test_frame_var_errors_when_archive_missing (TestBSDArchives.BSDArchivesTestCase)
FAIL: LLDB (~/llvm-upstream/Debug/bin/clang-arm64) :: test_frame_var_errors_when_mtime_mistmatch_for_object_in_archive (TestBSDArchives.BSDArchivesTestCase)
PLEASE submit a bug report to https://github.com/llvm/llvm-project/issues/ and include the crash backtrace.
Stack dump:
0. HandleCommand(command = "b a")
1. HandleCommand(command = "breakpoint set --name 'a'")
Fatal Python error: Segmentation fault
Current thread 0x00000001f7b99e00 (most recent call first):
File "~/llvm-upstream/Debug/bin/LLDB.framework/Resources/Python/lldb/__init__.py", line 3270 in HandleCommand
File "~/llvm-upstream/llvm-project/lldb/packages/Python/lldbsuite/test/lldbtest.py", line 2070 in runCmd
File "~/llvm-upstream/llvm-project/lldb/packages/Python/lldbsuite/test/lldbtest.py", line 2421 in expect
File "~/llvm-upstream/llvm-project/lldb/test/API/functionalities/archives/TestBSDArchives.py", line 156 in test_frame_var_errors_when_thin_archive_malformed
...
```
Differential Revision: https://reviews.llvm.org/D156367
This patch fixes a 32bit integer overflow in lldb-vscode.
The current implementation of frame_id does `(thread_index << 19 | frame_index)`. Since thread_index is a 32 bit integer this leaves only 32 - 19 == 13 bits available for the thread_index. As a result, lldb-vscode can only handle 2^13 == 8192 threads. Normally, this would be sufficient, but we have seen crazy process having +12000 threads, causing the frame_id algorithm above to integer overflow during casting.
The patch fixes the overflow by up casting to 64 bit integer first before bit shifiting.
Differential Revision: https://reviews.llvm.org/D156375
When we build the Clang module compilation command (e.g., when
a user requests import of a module via `expression @import Foundation`),
LLDB will try to determine which SDK directory to use as the `sysroot`.
However, it currently does so by simply enumerating the `SDKs` directory
and picking the last one that's appropriate for module compilation
(see `PlatformDarwin::GetSDKDirectoryForModules`). That means if we have
multiple platform SDKs installed (e.g., a public and internal one), we
may pick the wrong one by chance.
On Darwin platforms we emit the SDK path that a object
file was compiled against into DWARF (using `DW_AT_LLVM_sysroot`
and `DW_AT_APPLE_sdk`). For Swift debugging, we already parse the SDK
path from debug-info if we can.
This patch mimicks the Swift behaviour for non-Swift languages. I.e.,
if we can get the SDK path from debug-info, do so. Otherwise, fall back
to the old heuristic.
rdar://110407148
Differential Revision: https://reviews.llvm.org/D156020
With D149091, ARM64X binaries are no longer reported as ARM64. This broke
lldb tests as Windows 11 system DLLs are mostly ARM64X binaries and lldb
doesn't know how to handle them. Ideally lldb would understand a bit more
about ARM64X and handle them as AMD64 in x64 processes, but this is
enough to preserve previous behavior and fix tests.
Reviewed By: mstorsjo
Differential Revision: https://reviews.llvm.org/D156268
This changes the TLS regset to not only be dynamic in that it could
exist or not (though it always does) but also of a dynamic size.
If SME is present then the regset is 16 bytes and contains both tpidr
and tpidr2.
Testing is the same as tpidr. Write from assembly, read from lldb and
vice versa since we have no way to predict what its value should be
by just running a program.
Reviewed By: omjavaid
Differential Revision: https://reviews.llvm.org/D154930
The Scalable Matrix Extension (SME) adds a new Scalable Vector mode
called "streaming SVE mode".
In this mode a lot of things change, but my understanding overall
is that this mode assumes you are not going to move data out of
the vector unit very often or read flags.
Based on "E1.3" of "Arm® Architecture Reference Manual Supplement,
The Scalable Matrix Extension (SME), for Armv9-A".
https://developer.arm.com/documentation/ddi0616/latest/
The important details for debug are that this adds another set
of SVE registers. This set is only active when we are in streaming
mode and is read from a new ptrace regset NT_ARM_SSVE.
We are able to read the header of either mode at all times but
only one will be active and contain register data.
For this reason, I have reused the existing SVE state. Streaming
mode is just another mode value attached to that state.
The streaming mode registers do not have different names in the
architecture, so I do not plan to allow users to read or write the
inactive mode's registers. "z0" will always mean "z0" of the active
mode.
Ptrace does allow reading inactive modes, but the data is of little
use. Writing to inactive modes will switch to that mode which would
not be what a debugger user would expect. So lldb will do neither.
Existing SVE tests have been updated to check streaming mode and
mode switches. However, we are limited in what we can check given
that state for the other mode is invalidated on mode switch.
The only way to know what mode you are in for testing purposes would
be to execute a streaming only, or non-streaming only instruction in
the opposite mode. However, the CPU feature smefa64 actually allows
all non-streaming mode instructions in streaming mode.
This is enabled by default in QEMU emulation and rather than mess
about trying to disable it I'm just going to use the pseduo streaming
control register added in a later patch to make these tests more
robust.
A new test has been added to check SIMD read/write from all the modes
as there is a subtlety there that needs noting, though lldb
doesn't have to make extra effort to do so.
If you are in streaming mode and write to v0, when you later exit
streaming mode that value may not be in the non-streaming state.
This can depend on how the core works but is a valid behaviour.
For example, say I am stopped here:
mov x0, v0.d[0]
And I want to update v0 in lldb. "register write v0 ..." should update
the v0 that this instruction is about to see. Not the potential other
copy of v0 in the non-streaming state (which is what I attempted in
earlier versions of this patch).
Not to mention, switching out of streaming mode here would be unexpected
and difficult to signal to the user.
Reviewed By: omjavaid
Differential Revision: https://reviews.llvm.org/D154926
Increase the default timeouts when running under ASan. We had something
similar before we adopted tablegen, but the larger timeouts got lost in
the transition, possibly because tablegen's preprocessor support is very
limited. This patch passes a new define (LLDB_SANITIZED) to
lldb-tablegen on which we can base the default value.
Differential revision: https://reviews.llvm.org/D156279
As of 0beffb8542 there is a CMake
function to actually calculate the relative path to the clang resource
directory. Currently we have some bespoke logic that looks in a few
places, but with this new function we should be able to eliminate some
complexity here.
Also, I moved the functionality from LLDBConfig to LLDBStandalone since
it is only used in standalone builds.
Differential Revision: https://reviews.llvm.org/D156270
When the process is contiuned using an lldb command expression the thread state in VS Code is never informed and will be out of sync with the current state of the process. The new event will fire whenever the process is continued and keeps the debugger in sync with the dap client.
Reviewed By: wallace
Differential Revision: https://reviews.llvm.org/D154989
This is an enhancement for the locate module callback.
https://discourse.llvm.org/t/rfc-python-callback-for-target-get-module/71580/6
On Android remote platform, module UUID is resolved by
Platform::GetRemoteSharedModule. Which means the current
Target::CallLocateModuleCallbackIfSet() call undesirably is not able to pass the
module UUID to the locate module callback.
This diff moves the CallLocateModuleCallbackIfSet() implementation from Target
to Platform to allows both Target and Platform can call it. One is from the
current Target call site, and second is from Platform after resolving the module
UUID.
As the result of this change, the locate module callback may be called twice
for a same module on remote platforms. And it should be ok.
- First, without UUID.
- The locate module callback is allowed to return an error
if the callback requires UUID.
- Second, with UUID, if the first callback call did not return a module.
Differential Revision: https://reviews.llvm.org/D156066
Since 5d66f9fd8e this test has
been upassing on Linaro's Windows on Arm lldb bot:
https://lab.llvm.org/buildbot/#/builders/219/builds/4320
I can't explain exactly how that happened, but I do see a bunch
of QEnvironment packets going by in that test. It is very likely
that the order would have been different on Windows.
Indeed, when it was xfailed back in df9051e7cf
the reason was not known either.
Similar to ae316ac66f for
QEMU_(UN)SET_ENV.
The iteration order of StringMap is not guaranteed to be deterministic.
Sort the entries to give deterministic packets for the tests added by
D108018.
This patch adds the ability to pass native types from the script
interpreter to methods that use a {SB,}StructuredData argument.
To do so, this patch changes the `ScriptedObject` struture that holds
the pointer to the script object as well as the originating script
interpreter language. It also exposes that to the SB API via a new class
called `SBScriptObject`.
This structure allows the debugger to parse the script object and
convert it to a StructuredData object. If the type is not compatible
with the StructuredData types, we will store its pointer in a
`StructuredData::Generic` object.
This patch also adds some SWIG typemaps that checks the input argument to
ensure it's either an SBStructuredData object, in which case it just
passes it throught, or a python object that is NOT another SB type, to
provide some guardrails for the user.
rdar://111467140
Differential Revision: https://reviews.llvm.org/D155161
Signed-off-by: Med Ismail Bennani <ismail@bennani.ma>
This rewrites DW_OP_addrx inside DWARFExpression as an DW_OP_addr so
that we can update addresses that are originally located in the
debug_addr section.
The full discussion behind this can be found in
https://discourse.llvm.org/t/dwarfexpression-and-dw-op-addrx/71627/12, but a
summary follows.
When SymbolFileDWARF::ParseVariableDIE creates DWARFExpressions for
variables whose location is an OP_addr, it knows how to remap
addresses appropriately in the DebugMap case. It then calls
DWARFExpression::Update_DW_OP_addr, which updates the value associated
with OP_addr.
However, when we have an OP_addrx, the update function does
nothing. This makes sense, as the DWARFExpression does not have a
mutable view of the debug_addr section. In non-DebugMap flows this is
not an issue, as the debug_addr contains the correct addresses of
variables. In DebugMap flows, this is problematic because the work
done by RelinkOSOAddress is lost. By updating the OP to OP_addr, we
can also update the address as required,
We also explored the alternative of relinking the debug_addr section
when we are initializing OSOs (InitOSO). However, this creates an
inconsistent story for users of
DWARFExpression::GetLocation_DW_OP_addr. This function returns an
address without telling callers whether that address came from an
OP_addr or an OP_addrx. If we preemptively relink OP_addrx results
without doing the same for OP_addr results, then callers can’t know
whether the address they got was an executable address or an object
file address. In other words, they can’t know whether they need to
call LinkOSOFileAddress on those results or not.
This patch addresses the majority of test failures when enabling DWARF
5 for MachO (over 200 test failures).
Differential Revision: https://reviews.llvm.org/D155198
/data/llvm-project/lldb/source/Plugins/Process/Utility/RegisterInfos_x86_64_with_base_shared.cpp:319:1: error: non-void function does
not return a value in all control paths [-Werror,-Wreturn-type]
}
^
1 error generated.
Classes implemented in Swift can be exposed to ObjC. For those classes, the ObjC
metadata is incomplete. Specifically, the encoded types of the ivars are incomplete. As
one might expect, the Swift metadata _is_ complete. In such cases, the Swift runtime
should be consulted when determining the dynamic type of a value.
Differential Revision: https://reviews.llvm.org/D152837
Summary:
[lldb][x86_64] This patch adds fs_base/gs_base support for Linux x86_64.
Originally, I plan to split the diff into two parts, one to refactoring lldb_xxx_x86_64 => x86_64::lldb_xxx across code base and the other one for adding fs_base/gs_base, but it turns out to be a non-trivial effort to split and very error prone so I decided to keep a single diff to get feedback.
GDB supports fs_base/gs_base registers while LLDB does not. Since both linux coredump note section and ptrace
supports them it is a missing feature.
For context, this is a required feature to support getting pthread pointer on linux from both live and dump debugging.
See thread below for details:
https://discourse.llvm.org/t/how-to-get-pthread-pointer-from-lldb/70542/2?u=jeffreytan81
Implementation wise, we have initially tried `#ifdef` approach to reuse the code but it is introducing very tricky bugs and proves
hard to maintain. Instead the diff completely separates the registers between x86_64 and x86_64_with_base so that non-linux related
implementations can use x86_64 registers while linux uses x86_64_with_base.
Here are the list of changes done in the patch:
* Registers in lldb-x86-register-enums.h are separated into two: x86_64 and x86_64_with_base
* fs_base/gs_base are added into x86_64_with_base
* All linux files are change to use x86_64::lldb_xxx => x86_64_with_base::lldb_xxx
* Support linux elf-core:
* A new RegisterContextLinuxCore_x86_64 class is added for ThreadElfCore
* RegisterContextLinuxCore_x86_64 overrides and uses its own register set supports fs_base/gs_base
* RegisterInfos_x86_64_with_base/RegisterInfos_x86_64_with_base_shared ared added to provide g_contained_XXX/g_invalidate_XXX and RegInfo related code sharing.
* `RegisterContextPOSIX_x86 ::m_gpr_x86_64` seems to be unused so I removed it.
* `NativeRegisterContextDBReg_x86::GetDR()` is overridden in `NativeRegisterContextLinux_x86_64` to make watchpoint work.
Reviewers:clayborg,labath,jingham,jdoerfert,JDevlieghere,kusmour,GeorgeHuyubo
Subscribers:
Tasks:
Tags:
Differential Revision: https://reviews.llvm.org/D155256
Reading through the Watchpoint class, I found this method
that wasn't being used properly, and a couple of ivars that
weren't used at all. Cleanup.
Differential Revision: https://reviews.llvm.org/D155768
Currently frame var --regex sometimes searches globals, sometimes it doesn't.
This happens because `StackFrame::GetVariableList` always returns the biggest
list it has, regardless of whether only globals were requested or not. In other
words, if a previous call to `GetVariableList` requested globals, all subsequent
calls will see them.
The implication here is that users of `StackFrame::GetVariableList` are expected
to filter the results of this function. This is what we do for a vanilla
`frame var` command. But it is not what we do when `--regex` is used. This
commit solves the issue by:
1. Making `--regex` imply `--globals`. This matches the behavior of `frame var
<some_name>`, which will also search the global scope.
2. Making the `--regex` search respect the command object options.
See the added test for an example of the oddities this patch addresses. Without
the patch, the test fails. However it could be made to pass by calling a plain
`frame var` before calling `frame var --regex A::`.
Differential Revision: https://reviews.llvm.org/D155334
This adds a new flag and lldb runtime command to allow users to manage the behavior of the lldb-vscode evaluate repl request.
When evaluating a repl context this now has runtime managed flag for control how the repl behaviors with the follow values:
* `variable` - the existing behavior, with this mode requests are evaluted in the current frame context as variable expressions. To trigger a lldb command prefix an expression with ` and it will be evaluted as an lldb command.
* `command` - all expressions are evaluated as lldb commands.
* `auto` - An alternative mode that will attempt to determine if the expression is an lldb command or a variable expression. Based off the intepreted results the expression will be evaluted either as a command or an expression.
Additionally, I enabled completions and ensured they work with the new repl expression behavior to provide auto-completes.
This commit includes updates to the tests to verify the new behavior after the previous failures from submitting https://reviews.llvm.org/D154030.
Differential Revision: https://reviews.llvm.org/D155248
On a subsequent commit, I intend to update the expression and call the evaluate
function more times. This refactors enables reusing some of the existing code
for that.
Differential Revision: https://reviews.llvm.org/D155197
It was implicitly assumning that "/" would have no files in it, only
directories. That's not true, for instance on macOS if you've navigated
to the root directory in the Finder...
Since we're assuming everything we check against is a directory, then we
need to filter the completion for that coming in.
"sme" is just one of many cpuinfo features for SME but it's the
only one we need for testing.
The rest are related to the use of certain instructions and
don't change the register state available.
Reviewed By: omjavaid
Differential Revision: https://reviews.llvm.org/D154823
This test runs to a breakpoint on thread 0. Thread 0 then starts
thread 2 and 3, which both have breakpoints in them.
In https://lab.llvm.org/buildbot/#/builders/96/builds/41674
I think that we managed to do the first check on thread 2 before
thread 3 had started. Therefore "thread continue 3" failed.
So wait for all three to startup before we check their status.
I considered putting a timeout on the while like the wait_for... methods,
but the test itself already has a global timeout. Plus, I'd rather
not be tuning a timeout per piece of hardware this runs on.
99% of the time we will already have 3 threads when the check is done.
Reviewed By: omjavaid
Differential Revision: https://reviews.llvm.org/D154705
This reverts commit 668a3efd42.
Reverting because of build errors:
In file included from /Users/buildslave/jenkins/workspace/as-lldb-cmake/llvm-project/lldb/source/API/SBPlatform.cpp:19:
/Users/buildslave/jenkins/workspace/as-lldb-cmake/llvm-project/lldb/include/lldb/Target/Target.h:1035:18: warning: parameter 'merged' not found in the function declaration [-Wdocumentation]
This reverts commit df054499c3.
Reverting because of build errors
In file included from /Users/buildslave/jenkins/workspace/as-lldb-cmake/llvm-project/lldb/source/API/SBPlatform.cpp:19:
/Users/buildslave/jenkins/workspace/as-lldb-cmake/llvm-project/lldb/include/lldb/Target/Target.h:1035:18: warning: parameter 'merged' not found in the function declaration [-Wdocumentation]
This reverts commit 7f1028e9df.
This is because test failures
lldb-unit.Target/_/TargetTests/LocateModuleCallbackTest.GetOrCreateModuleWithCachedModule
lldb-unit.Target/_/TargetTests/LocateModuleCallbackTest.GetOrCreateModuleWithCachedModuleAndBreakpadSymbol
This reverts commit fb087c17c8.
This is because of test failures:
lldb-unit.Target/_/TargetTests/LocateModuleCallbackTest.GetOrCreateModuleWithCachedModule
lldb-unit.Target/_/TargetTests/LocateModuleCallbackTest.GetOrCreateModuleWithCachedModuleAndBreakpadSymbol
Add support for compressed CTF data. The flags in the header can
indicate whether the CTF body is compressed with zlib deflate. This
patch supports inflating the data before parsing.
Differential revision: https://reviews.llvm.org/D155221
In preparation for removing the #include "llvm/ADT/StringExtras.h"
from the header to source file of llvm/Support/Error.h, first add in
all the missing includes that were previously included transitively
through this header.
This is fixing all files missed in b0abd4893f, 39d8e6e22c,
a11efd4926, 5551657b31, and 90bfe2df25.
Differential Revision: https://reviews.llvm.org/D155178
Add support for the Compact C Type Format (CTF) in LLDB. The format
describes the layout and sizes of C types. It is most commonly consumed
by dtrace.
We generate CTF for the XNU kernel and want to be able to use this in
LLDB to debug kernels for which we don't have dSYMs (anymore). CTF is a
much more limited debug format than DWARF which allows is to be an order
of magnitude smaller: a 1GB dSYM can be converted to a handful of
megabytes of CTF. For XNU, the goal is not to replace DWARF, but rather
to have CTF serve as a "better than nothing" debug info format when
DWARF is not available.
It's worth noting that the LLVM toolchain does not support emitting CTF.
XNU uses ctfconvert to generate CTF from DWARF which is used for
testing.
Differential revision: https://reviews.llvm.org/D154862
This code was introduced in 2fc93eabf7.
In order to improve readability of ParseVariableDIE, we move this code into a
helper function. The issue this code attempted to address was fixed between
Clangs 9 and 11; as such, if we ever want to delete this code, it is a lot
easier to do so after the refactor.
Differential Revision: https://reviews.llvm.org/D155100
In preparation for removing the #include "llvm/ADT/StringExtras.h"
from the header to source file of llvm/Support/Error.h, first add in
all the missing includes that were previously included transitively
through this header.
This is fixing all files missed in b0abd4893f, 39d8e6e22c,
a11efd4926, and 5551657b31.
Differential Revision: https://reviews.llvm.org/D155018
When we attach to a process, we task_for_pid(), ptrace(), and then
we try to halt execution of the process and time out after thirty
seconds if we cannot interrupt it. At this point, we must assume
we have no control of the inferior process and the attach has failed.
The error message we return currently is "operation timed out"; this
change improves on that error message to make it more clear what is
going on. Thanks to Jim for pointing this out.
rdar://101152233
When debugserver is attaching to a process, it first task_for_pid()'s
and then ptrace(PT_ATTACHEXC)'s. When that ptrace() fails to complete,
we are in a semi-attached state that we need to give up from, and
our error reporting isn't ideal -- we can even claim that the process
is already being debugged (by ourselves).
Differential Revision: https://reviews.llvm.org/D155037
rdar://101152233
"line 0" in a DWARF linetable means something that doesn't have associated
source. The code for mixed disassembly has a comment indicating that
"line 0" should be skipped, but the wrong value was returned. Fix the return
value and add a test to check that we don't incorrectly show source lines
from the beginning of the file.
Reviewed By: jasonmolenda
Differential Revision: https://reviews.llvm.org/D112931
This adds a new flag and lldb runtime command to allow users to manage the behavior of the lldb-vscode evaluate repl request.
When evaluating a repl context this now has runtime managed flag for control how the repl behaviors with the follow values:
* `variable` - the existing behavior, with this mode requests are evaluted in the current frame context as variable expressions. To trigger a lldb command prefix an expression with ` and it will be evaluted as an lldb command.
* `command` - all expressions are evaluated as lldb commands.
* `auto` - An alternative mode that will attempt to determine if the expression is an lldb command or a variable expression. Based off the intepreted results the expression will be evaluted either as a command or an expression.
Additionally, I enabled completions and ensured they work with the new repl expression behavior to provide auto-completes.
RFC Discussion: https://discourse.llvm.org/t/rfc-lldb-vscode-evaluate-repl-behavior-and-improvements/71667
Reviewed By: wallace
Differential Revision: https://reviews.llvm.org/D154030
I need to call this to figure out why the assert in
StopInfoMachException::CreateStopReasonWithMachException is triggering, but
it isn't appropriate to directly access the GDBRemoteCommunication there. And
dumping whatever history the process plugin has collected during the run isn't
gdb-remote specific...
Differential Revision: https://reviews.llvm.org/D154992
These methods all take a `Stream *` to get feedback about what's going
on. By default, it's a nullptr, but we always feed it with a valid
pointer. It would therefore make more sense to have this take a
reference.
Differential Revision: https://reviews.llvm.org/D154883
A common thing to do is to call `str().c_str()` to get a null-terminated
string out of an existing StringRef. Most of the time this is to be able
to use a printf-style format string. However, llvm::formatv can handle
StringRefs without the need for the additional allocation. Using that
makes more sense.
Differential Revision: https://reviews.llvm.org/D154890
In two calls to ReadMemory in DWARFExpression.cpp, the buffer size
passed to ReadMemory is not checked and can be bigger than the actual
size of the buffer. This caused a buffer overflow bug, which we
found through Address Sanitizer. This patch fixes the problem by
checking the address size when it is first read out of the DWARF, and
setting an error and returning immediatley if the size is invalid.
This is the second attempt to fix this issue; I reverted the first one,
as it was not quite correct.
Differential Revision: https://reviews.llvm.org/D154907
This reverts commit ee476996be.
That commit was not the right way to fix the issue (it could result in
reading too many bytes). A better fix is in the works.
Original review: https://reviews.llvm.org/D153840
Fix a crash when trying to complete an ambiguous subcommand. Take `set s
tar` for example: for the subcommand `s` there's ambiguity between set
and show. Pressing TAB after this input currently crashes LLDB. The
problem is that we're trying to complete `tar` but give up at `s`
because of the ambiguity. LLDB doesn't expect the completed string to be
shorter than the current string and crashes when trying to eliminate the
common prefix.
rdar://111848598
Differential revision: https://reviews.llvm.org/D154643
-g is specified by passing in nullptr ExecutionContext, but in some
load-script-from-symbol-file specific code, the ExecutionContext was
asked for its Target w/o checking whether the pointer was null.
Fix that and add a test.
`Instruction::TestEmulation` takes a `Stream *` and checks it for validity.
However, this is unnecessary as we can always ensure that we never pass
`nullptr` for the `Stream` argument. The only use of
`Instruction::TestEmulation` currently is `SBInstruction::TestEmulation`
which gets the `Stream` from an `SBStream`, and `SBStream::ref` can
return a `Stream &` guaranteed.
Differential Revision: https://reviews.llvm.org/D154757
The ordering in which functions are presented to the expression evaluator in
this test setting triggers a known bug in LLDB.
Differential Revision: https://reviews.llvm.org/D154843
In preparation for removing the `#include "llvm/ADT/StringExtras.h"`
from the header to source file of `llvm/Support/Error.h`, first add in
all the missing includes that were previously included transitively
through this header.
This is fixing all files missed in b0abd4893f, 39d8e6e22c, and
a11efd4926.
Differential Revision: https://reviews.llvm.org/D154775
In preparation for removing the `#include "llvm/ADT/StringExtras.h"`
from the header to source file of `llvm/Support/Error.h`, first add in
all the missing includes that were previously included transitively
through this header.
This is fixing all files missed in b0abd4893f and
39d8e6e22c.
Differential Revision: https://reviews.llvm.org/D154763
In order to recognize namespace aliases as a namespace, the
DW_TAG_imported_declaration has to be taken into account. The name of these DIEs
is already included in all accelerator tables as of D143397.
Two of the three Index classes already handle this correctly:
1. ManualDWARFIndex (as of D143398)
2. AppleDWARFIndex works by default with D143397, since apple has a table
dedicated to namespaces.
This commit updates the third index class, DWARF 5's DebugNamesDWARFIndex.
As a result, it fixes the following test with DWARF 5:
commands/expression/namespace-alias/TestInlineNamespaceAlias.py
Differential Revision: https://reviews.llvm.org/D154730
dyld has two notification functions - a native one, and one that
it rewrites its arguments for, for lldb. We currently use the
latter, _dyld_debugger_notification. The native notification
function, lldb_image_notifier (and on older systems, gdb_image_notifier)
we can find by name, or if libdyld shows no dyld loaded in the
process currently, we can get it from the dyld_all_image_infos
object in memory which we can find with a system call. When we do
a "waitfor attach" to a process on a modern darwin system, there
is a transition early in launch from the launch dyld to the
shared-cache-dyld, and when we attach in the middle of that transition,
libdyld will say there is no dyld present. But we can still find
the in-memory dyld_all_image_infos which has the address of the
shared cache notifier function that will be registered in the
process soon.
This change will result in a much more reliable waitfor-attach.
This is the third landing of this patch. We have an Intel mac
CI bot that is running an older (c. 2019) macOS 10.15, I had to
reproduce that environment and found the name of the notifier
function had changed which was the cause of those failures.
Differential Revision: https://reviews.llvm.org/D139453
rdar://101194149
We always assume these streams are valid, might as well take references
instead of raw pointers.
Differential Revision: https://reviews.llvm.org/D154549
This function does a _lot_ of different things:
1. Parses a DIE,
2. Builds an ExpressionList
3. Figures out lifetime of variable
4. Remaps addresses for debug maps
5. Handles external variables
6. Figures out scope of variables
A lot of this functionality is coded in a complex nest of conditions, variables
that are declared and then initialized much later, variables that are updated in
multiple code paths. All of this makes the code really hard to follow.
This commit attempts to improve the state of things by factoring out (3), adding
documentation on how the expression list is built, and by reducing the scope of
variables.
Differential Revision: https://reviews.llvm.org/D154513
On Darwin systems, the dynamic linker dyld has an empty function
it calls when binaries are added/removed from the process. lldb puts
a breakpoint on this dyld function to catch the notifications. The
function arguments are used by lldb to tell what is happening.
The linker has a natural representation when the addresses of
binaries being added/removed are in the pointer size of the process.
There is then a second function where the addresses of the binaries
are in a uint64_t array, which the debugger has been using before -
dyld allocates memory for the array, copies the values in to it,
and calls it for lldb's benefit.
This changes to using the native notifier function, with pointer-sized
addresses.
This is the second time landing this change; this time correct the
size of the image_count argument, and add a fallback if the
notification function "lldb_image_notifier" can't be found.
Differential Revision: https://reviews.llvm.org/D139453
Also, make it possible for new Targets which haven't been added to
the TargetList yet to check for interruption, and add a few more
places in building modules where we can check for interruption.
Differential Revision: https://reviews.llvm.org/D154542
This patch attempts to fix a dead lock when loading modules in a Scripted
Process.
This issue was triggered by loading the modules after the process did resume,
but before the process actually stop, causing the language runtime mutex to
be locked by a separate thread, responsible to unwind the stack (using
the runtime unwind plan), while the module loading thread was trying to
notify the runtimes of the newly loaded module.
To address that, this patch moves the module loading logic to be done before
sending the stop event, to prevent the dead lock situation described above.
Differential Revision: https://reviews.llvm.org/D154649
Signed-off-by: Med Ismail Bennani <ismail@bennani.ma>
When LLDB queries the debug names index with a regex, we should use the
`Mangled` class wrapper, which attempts to match regex first against the mangled
name and then against the demangled name. It is important to do so, otherwise
queries like `frame var --regex A::` would never work. This is what is done for
the Apple index as well.
This fixes test/API/lang/cpp/class_static/main.cpp when compiled with DWARF 5.
Differential Revision: https://reviews.llvm.org/D154617
This accomplishes a few minor things:
- Removed unnecessary uses of `this->`
- Removed an unnecessary std::string allocation.
- Removed some nesting to improve readability using early returns where
it makes sense.
- Replaced `strtoul` with `llvm::to_integer` which avoids another
std::string allocation.
- Removed braces from single statement conditions, removed
else-after-returns.
Differential Revision: https://reviews.llvm.org/D154534
Summary: No need to create a ConstString, `GetName` already returns a StringRef.
Reviewers: JDevlieghere, mib, jasonmolenda
Subscribers:
Differential Revision: https://reviews.llvm.org/D154386
Two identical loops were iterating over different ranges, leading to code
duplication. We replace this by a loop over the concatenation of the ranges.
We also use early returns to avoid deeply nested code and explicitly check for a
condition mentioned in comments.
Differential Revision: https://reviews.llvm.org/D154505
Previously the following would crash:
(lldb) run
Process 2594053 launched: '/tmp/test.o' (aarch64)
Process 2594053 exited with status = 0 (0x00000000)
(lldb) register read <tab>
As the completer assumed that the execution context would always
have a register context. After a program has finished, it does not.
Split out the generic parts of the test from the x86 specific tests,
and added "register info" to both.
Reviewed By: JDevlieghere
Differential Revision: https://reviews.llvm.org/D154413
We're seeing a lot of test failures on the lldb incremental x86 CI bot
since I landed https://reviews.llvm.org/D139453 - revert it while I
investigate.
This reverts commit 624813a4f4.
Fix incorrect uses of formatv specifiers in LLDB_LOG. Unlike Python,
arguments must be numbered. All the affected log statements take
llvm:Errors so use the LLDB_LOG_ERROR macro instead.
Differential revision: https://reviews.llvm.org/D154532
Fix incorrect uses of LLDB_LOG_ERROR. The macro doesn't automatically
inject the error in the log message: it merely passes the error as the
first argument to formatv and therefore must be referenced with {0}.
Thanks to Nicholas Allegra for collecting a list of places where the
macro was misused.
rdar://111581655
Differential revision: https://reviews.llvm.org/D154530
This does 2 things:
- Corrects a minor typo (`value subvalue` -> `valid subvalue`)
- Removes an unnecessary instance of `str().c_str()` (creating a
temporary std::string from a StringRef just to get a valid
null-terminated string).
Differential Revision: https://reviews.llvm.org/D154387
This method, as far as I can ascertain, is non-trivial to actually use
to work with (if not impossible). It doesn't make sense to use from
Python and you do not have access to the accompanying TypeSystem, so it
doesn't really do anything useful.
A possible follow-up is to gut the implementation and have it return `nullptr`.
Differential Revision: https://reviews.llvm.org/D153918
For some context, Raphael tried to this before: https://reviews.llvm.org/D104231
These methods are not tested at all, and in some cases, are not even fully
implemented (e.g. SBHostOS::ThreadCreated). I'm not convinced it's
possible to use these correctly from Python, and I'm not aware of any
users of these methods. It's difficult to remove these methods
wholesale, but we can start with deprecating them.
A possible follow-up to this change (which may require an RFC to get
more buy in from the community) is to gut these functions entirely. That
is, remove the implementations and replace them either with nothing or
have them dump out a message to stderr saying not to use these.
Differential Revision: https://reviews.llvm.org/D153900
This test previously ran on QEMU or A64FX both of which can/do have
512 bit SVE by default.
Graviton 3 has 256 bit SVE so the first part of the test failed.
To fix this, probe the supported vector lengths before starting
the test. The first check will use the default vector length and
the rest use either 256 or 128 bit.
Therefore this test will be skipped on a machine with only 128 bit SVE.
Reviewed By: omjavaid
Differential Revision: https://reviews.llvm.org/D154208
During __do_global_dtors_aux glibc sets a flag that is right
next to the global variable. This is done using a store byte.
On QEMU the watchpoints are handled with a finer granularity
than real hardware, so this wasn't a problem. On Graviton 3
(and Mountain Jade, though this test won't run there) watchpoints
look at larger chunks of memory.
This means that the final continue actually stops in __do_global_dtors_aux
instead of exiting.
We could fix this by padding the global to be away from the flag,
but that is fiddly and it is easier just to remove the watchpoint
before the final continue. We have already verified it worked by that
point.
Reviewed By: omjavaid
Differential Revision: https://reviews.llvm.org/D154201
Running this on Amazon Ubuntu the final backtrace is:
```
(lldb) thread backtrace
* thread #1, name = 'a.out', stop reason = breakpoint 1.1
* frame #0: 0x0000aaaaaaaa07d0 a.out`func_c at main.c:10:3
frame #1: 0x0000aaaaaaaa07c4 a.out`func_b at main.c:14:3
frame #2: 0x0000aaaaaaaa07b4 a.out`func_a at main.c:18:3
frame #3: 0x0000aaaaaaaa07a4 a.out`main(argc=<unavailable>, argv=<unavailable>) at main.c:22:3
frame #4: 0x0000fffff7b373fc libc.so.6`___lldb_unnamed_symbol2962 + 108
frame #5: 0x0000fffff7b374cc libc.so.6`__libc_start_main + 152
frame #6: 0x0000aaaaaaaa06b0 a.out`_start + 48
```
This causes the test to fail because of the extra ___lldb_unnamed_symbol2962 frame
(an inlined function?).
To fix this, strictly check all the frames in main.c then for the rest
just check we find __libc_start_main and _start in that order regardless
of other frames in between.
Reviewed By: omjavaid
Differential Revision: https://reviews.llvm.org/D154204
We recently saw an uptick in internal reports complaining that LLDB is
slow when sources on network file systems are inaccessible. I looked at
the SourceManger and its cache and I think there’s some room for
improvement in terms of reducing file system accesses:
1. We always resolve the path.
2. We always check the timestamp.
3. We always recheck the file system for negative cache hits.
D153726 fixes (1) but (2) and (3) are necessary because of the cache’s
current design. Source files are cached at the debugger level which
means that the source file cache can span multiple targets and
processes. It wouldn't be correct to not reload a modified or new file
from disk.
We can however significantly reduce the number of file system accesses
by using a two level cache design: one cache at the debugger level and
one at the process level:
- The cache at the debugger level works the way it does today. There is
no negative cache: if we can't find the file on disk, we'll try again
next time the cache is queried. If a cached file's timestamp changes
or if its path remapping changes, the cached file is evicted and we
reload it from disk.
- The cache at the process level is design to avoid accessing the file
system. It doesn't check the file's modification time. It caches
negative results, so if a file didn't exist, it doesn't try to reread
it from disk. Checking if the path remapping changed is cheap
(doesn't involve checking the file system) and is the only way for a
file to get evicted from the process cache.
The result of this patch is that LLDB will not show you new content if a
file is modified or created while a process is running. I would argue
that this is what most people would expect, but it is a change from how
LLDB behaves today.
For an average stop, we query the source cache 4 times. With the current
implementation, that's 4 stats to get the modification time, If the file
doesn't exist on disk, that's an additional 4 stats. Before D153726, if
the path starts with a ~ there are another additional 4 calls to
realpath. When debugging sources on a slow (network) file system, this
quickly adds up.
In addition to the two level caching, this patch also adds a source
logging channel and synchronization to the source file cache. The
logging was helpful during development and hopefully will help us triage
issues in the future. The synchronization isn't a new requirement: as
the cache is shared across targets, there is no guarantees that it can't
be accessed concurrently. The patch also fixes a bug where we would only
set the source remapping ID if the un-remapped file didn't exist, which
led to the file getting evicted from the cache on every access.
rdar://110787562
Differential revision: https://reviews.llvm.org/D153834
The make_shared function never returns a nullptr, as such the test for nullptr
is not needed. We also move the empty string check earlier in the if
("oso_object"), as this is cheaper than loading the object file.
Differential Revision: https://reviews.llvm.org/D154365
This patch should fix some data races when a python script (i.e. a
Scripted Process) has a nested call to another python script (i.e. a
OperatingSystem Plugin), which can cause concurrent writes to the python
lock count.
This patch also fixes a data race happening when resetting the operating
system unique pointer.
To address these issues, both accesses is guarded by a mutex.
rdar://109413039
Differential Revision: https://reviews.llvm.org/D154271
Signed-off-by: Med Ismail Bennani <ismail@bennani.ma>
We already have LLDB_DEPRECATED which is used to mark methods as
deprecated with a message and an alternative to use instead. This is
expresses an intent of "We recognize this functionality is useful but
there are some pitfalls with the interface we have exposed."
In other cases, there are no "alternative" methods to use and the code should be
refactored to avoid using a method entirely. For example,
`SBValue::Cast` should be avoided in favor of using the expression
evaluator to perform a cast. There isn't a mechanical solution, the
recommendation is to instead refactor your code.
This commit renames the existing `LLDB_DEPRECATED` to
`LLDB_DEPRECATED_FIXME`, and adds a `LLDB_DEPRECATED` macro to cover the
second scenario.
Differential Revision: https://reviews.llvm.org/D153928
I'm not convinced that it makes sense for the paths to be ConstStrings. We're
going to be putting them into FileSpecs (which are backed by
ConstStrings, for now) but otherwise there's no need to store them as
ConstStrings upfront.
Differential Revision: https://reviews.llvm.org/D153827
Instead of just returning a raw `const char *`, I think llvm::StringRef
would make more sense. Most of the time that we use the return value of
`GetProcessPluginName` we're passing it to `CreateProcess` which takes a
StringRef anyway.
Differential Revision: https://reviews.llvm.org/D153825
This doesn't really use fast comparison or string uniqueness. In fact,
all of the current callers pass an empty string for type_name. The only
reason I don't remove it is because it looks like it is used downstream
for swift.
Differential Revision: https://reviews.llvm.org/D153810
2/3 of the ConstStrings in this class were just to be able to log
something. Putting something in the StringPool just to log it doesn't
make a lot of sense, so let's remove them.
The remaining use is for `RegisterPersistentDecl` which is fine for now.
Differential Revision: https://reviews.llvm.org/D153905
A very old commit (9422dd64f8) changed the signature of this function in a
number of ways. This patch aims to improve it:
1. Reword the documentation, which still mentions old parameters that no longer
exist, and to elaborate upon the behavior of this function.
2. Remove the unnecessary parameter `op_addr_idx`. This parameter is odd in a
couple of ways: we never use it with a value that is non-zero, and the matching
`Update_DW_OP_addr` function doesn't use a similar parameter. We also document
that this new behavior. If we ever decide to handle multiple "DW_OP_addr", we
can introduce the complexity again.
Differential Revision: https://reviews.llvm.org/D154265
D68678 added a test that ensures an Apple accelerator lookup is done
efficiently. Since these tables are not used for DWARF 5, we should decorate the
test appropriately.
Differential Revision: https://reviews.llvm.org/D154268
