This changes the decorator helper `_match_decorator_property` to
consider `None` as the actual value as not a match. Using `None` for the
pattern continues to be considered a match.
I discovered the issue because marking a test as NO_DEBUG_INFO_TESTCASE
will cause the call to `self.getDebugInfo()` to return `None` and
incorrectly skip or XFAIL the corresponding test.
I used the above scenario to create a test for the decorators.
Differential revision: https://reviews.llvm.org/D123401
Unlike for any of the other shells, we were escaping $ when using tcsh.
There's nothing special about $ in tcsh and this prevents you from
expanding shell variables, one of the main reasons this functionality
exists in the first place.
Differential revision: https://reviews.llvm.org/D123690
The rust demangler has some odd buffer handling code, which will copy
the demangled string into the provided buffer, if it will fit.
Otherwise it uses the allocated buffer it made. But the length of the
incoming buffer will have come from a previous call, which was the
length of the demangled string -- not the buffer size. And of course,
we're unconditionally allocating a temporary buffer in the first
place. So we don't actually get buffer reuse, and we get a memcpy in
somecases.
However, nothing in LLVM ever passes in a non-null pointer. Neither
does anything pass in a status pointer that is then made use of. The
only exercise these have is in the test suite.
So let's just make the rust demangler have the same API as the dlang
demangler.
Reviewed By: tmiasko
Differential Revision: https://reviews.llvm.org/D123420
This patch moves the platform creation and selection logic into the
per-debugger platform lists. I've tried to keep functional changes to a
minimum -- the main (only) observable difference in this change is that
APIs, which select a platform by name (e.g.,
Debugger::SetCurrentPlatform) will not automatically pick up a platform
associated with another debugger (or no debugger at all).
I've also added several tests for this functionality -- one of the
pleasant consequences of the debugger isolation is that it is now
possible to test the platform selection and creation logic.
This is a product of the discussion at
<https://discourse.llvm.org/t/multiple-platforms-with-the-same-name/59594>.
Differential Revision: https://reviews.llvm.org/D120810
LLDB supports having globbing regexes in the process launch arguments
that will be resolved using the user's shell. This requires that we pass
the launch args to the shell and then read back the expanded arguments
using LLDB's argdumper utility.
As the shell will not just expand the globbing regexes but all special
characters, we need to escape all non-globbing charcters such as $, &,
<, >, etc. as those otherwise are interpreted and removed in the step
where we expand the globbing characters. Also because the special
characters are shell-specific, LLDB needs to maintain a list of all the
characters that need to be escaped for each specific shell.
This patch adds the missing semicolon character to the escape list for
all currently supported shells. Without this having a semicolon in the
binary path or having a semicolon in the launch arguments will cause the
argdumping process to fail. E.g., lldb -- ./calc "a;b" was failing
before but is working now.
Fixes rdar://55776943
Differential revision: https://reviews.llvm.org/D104629
Something ugly I did was to report the trace buffer size to the DecodedThread,
which is later used as part of the `dump info` command. Instead of doing that,
we can just directly ask the trace for the raw buffer and print its size.
I thought about not asking for the entire trace but instead just for its size,
but in this case, as our traces as not extremely big, I prefer to ask for the
entire trace, ensuring it could be fetched, and then print its size.
Differential Revision: https://reviews.llvm.org/D123358
I'm adding two new classes that can be used to measure the duration of long
tasks as process and thread level, e.g. decoding, fetching data from
lldb-server, etc. In this first patch, I'm using it to measure the time it takes
to decode each thread, which is printed out with the `dump info` command. In a
later patch I'll start adding process-level tasks and I might move these
classes to the upper Trace level, instead of having them in the intel-pt
plugin. I might need to do that anyway in the future when we have to
measure HTR. For now, I want to keep the impact of this change minimal.
With it, I was able to generate the following info of a very big trace:
```
(lldb) thread trace dump info Trace technology: intel-pt
thread #1: tid = 616081
Total number of instructions: 9729366
Memory usage:
Raw trace size: 1024 KiB
Total approximate memory usage (excluding raw trace): 123517.34 KiB
Average memory usage per instruction (excluding raw trace): 13.00 bytes
Timing:
Decoding instructions: 1.62s
Errors:
Number of TSC decoding errors: 0
```
As seen above, it took 1.62 seconds to decode 9.7M instructions. This is great
news, as we don't need to do any optimization work in this area.
Differential Revision: https://reviews.llvm.org/D123357
This means we don't have to remember to update this code as much.
This is all tested in lldb/test/Shell/Commands/command-disassemble-aarch64-extensions.s
which I added previously.
We don't have a way to get the latest base architecture yet
so that remains manual. Having all the extensions specified
will probably be equivalent to the latest architecture version
in any case.
Reviewed By: labath
Differential Revision: https://reviews.llvm.org/D123582
Places calling LoadModuleAtAddress() already call ModulesDidLoad()
after a loop calling LoadModuleAtAddress(), so it's not necessary
to call it from there, and the batched ModulesDidLoad() may be
more efficient than this place calling it one after one.
This also makes the ModuleLoadedNotifys test pass on Linux now that
the duplicates no longer bring down the average of modules notified
per call.
Differential Revision: https://reviews.llvm.org/D123128
Don't report progress events in the REPL. Most of the progress events
are debugger specific which are useful when you're debugging, but not so
much when you're waiting for the next line to be executed in the REPL.
This patch disables reporting of progress events when in REPL mode.
rdar://91502950
Differential revision: https://reviews.llvm.org/D123426
Move them to the only source file that included RegisterInfos_arm64.h
that actually used these variables.
This silences warnings like these:
In file included from lldb/source/Plugins/Instruction/ARM64/EmulateInstructionARM64.cpp:42:
lldb/source/Plugins/Process/Utility/RegisterInfos_arm64.h:790:35: warning: ‘g_register_infos_mte’ defined but not used [-Wunused-variable]
790 | static lldb_private::RegisterInfo g_register_infos_mte[] = {
| ^~~~~~~~~~~~~~~~~~~~
lldb/source/Plugins/Process/Utility/RegisterInfos_arm64.h:787:35: warning: ‘g_register_infos_pauth’ defined but not used [-Wunused-variable]
787 | static lldb_private::RegisterInfo g_register_infos_pauth[] = {
| ^~~~~~~~~~~~~~~~~~~~~~
Differential Revision: https://reviews.llvm.org/D123206
(With C++ exceptions, `clang++ --target=mips64{,el}-linux-gnu -fpie -pie
-fuse-ld=lld` has link errors (lld does not implement some strange R_MIPS_64
.eh_frame handling in GNU ld). However, sanitizer-x86_64-linux-qemu used this to
build ScudoUnitTests. Pined ScudoUnitTests to -no-pie.)
Default the option introduced in D113372 to ON to match all(?) major Linux
distros. This matches GCC and improves consistency with Android and linux-musl
which always default to PIE.
Note: CLANG_DEFAULT_PIE_ON_LINUX may be removed in the future.
Differential Revision: https://reviews.llvm.org/D120305
Clang is adding a feature to ObjC code generation, where instead of calling
objc_msgSend directly with an object & selector, it generates a stub that
gets passed only the object and the stub figures out the selector.
This patch adds support for following that dispatch method into the implementation
function.
We need to import foundation to get a 'NSLog' declaration when building
against the iOS SDK. This doesn't appear necessary when building against
the macOS SDK, presumable because it gets transitively imported by
objc/NSObject.h
Some parts of the code have to distinguish between live and postmortem threads
to figure out how to get some data, e.g. thread trace buffers. This makes the
code less generic and more error prone. An example of that is that we have
two different decoders: LiveThreadDecoder and PostMortemThreadDecoder. They
exist because getting the trace bufer is different for each case.
The problem doesn't stop there. Soon we'll have even more kinds of data, like
the context switch trace, whose fetching will be different for live and post-
mortem processes.
As a way to fix this, I'm creating a common API for accessing thread data,
which is able to figure out how to handle the postmortem and live cases on
behalf of the caller. As a result of that, I was able to eliminate the two
decoders and unify them into a simpler one. Not only that, our TraceSave
functionality only worked for live threads, but now it can also work for
postmortem processes, which might be useful now, but it might in the future.
This common API is OnThreadBinaryDataRead. More information in the inline
documentation.
Differential Revision: https://reviews.llvm.org/D123281
As we soon will need to decode multiple raw traces for the same thread,
having a class that encapsulates the decoding of a single raw trace is
a stepping stone that will make the coming features easier to implement.
So, I'm creating a LibiptDecoder class with that purpose. I refactored
the code and it's now much more readable. Besides that, more comments
were added. With this new structure, it's also easier to implement unit
tests.
Differential Revision: https://reviews.llvm.org/D123106
If the variables view shows a variable that is a struct that has
MightHaveChildren(), the expand diamond is shown, but if trying to expand
it and it's not possible (e.g. incomplete type), remove the expand diamond
to visualize that it can't be in fact expanded. Otherwise it feels kinda
weird that a tree item cannot be expanded even though it "should".
I guess the MightHaveChildren() checking means that GetChildren() may
be expensive, so also do not call it for rows that are not expanded.
Differential Revision: https://reviews.llvm.org/D123008
As noticed in D87637, when LLDB crashes, we only print stack traces if
LLDB is directly executed, not when used via Python bindings. Enabling
this by default may be undesirable (libraries shouldn't be messing with
signal handlers), so make this an explicit opt-in.
I "commandeered" this patch from Jordan Rupprecht who put this up for
review originally.
Differential revision: https://reviews.llvm.org/D91835
This warning gives false positives about lldb's correct use of
strncpy to fill fixed length fields that don't need null termination,
in lldb/source/Plugins/ObjectFile/Mach-O/ObjectFileMachO.cpp, like this:
In file included from /usr/include/string.h:495,
from /usr/include/c++/9/cstring:42,
from ../include/llvm/ADT/StringRef.h:19,
from ../tools/lldb/source/Plugins/ObjectFile/Mach-O/ObjectFileMachO.cpp:10:
In function ‘char* strncpy(char*, const char*, size_t)’,
inlined from ‘lldb::offset_t CreateAllImageInfosPayload(const ProcessSP&, lldb::offset_t, lldb_private::StreamString&, lldb::SaveCoreStyle)’ at ../tools/lldb/source/Plugins/ObjectFile/Mach-O/ObjectFileMachO.cpp:6341:16:
/usr/include/x86_64-linux-gnu/bits/string_fortified.h:106:34: warning: ‘char* __builtin_strncpy(char*, const char*, long unsigned int)’ specified bound 16 equals destination size [-Wstringop-truncation]
106 | return __builtin___strncpy_chk (__dest, __src, __len, __bos (__dest));
| ~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~
The warning could be squelched locally with
#pragma GCC diagnostic ignored "-Wstringop-truncation"
too, but Clang also interprets those GCC pragmas, and produces
a -Wunknown-warning-option warning instead. That could be remedied
by wrapping the pragma in an "#ifndef __clang__" - but that makes
things even more messy. Instead, just silence this warning entirely.
Differential Revision: https://reviews.llvm.org/D123254
debugserver does not call thread_set_state when changing xmm/ymm/zmm
register values, so the register contents are never updated. Fix
that. Mark the shell tests which xfail'ed these tests on darwin systems
to xfail them when the system debugserver, they will pass when using
the in-tree debugserver. When this makes it into the installed
system debugservers, we'll remove the xfails.
Differential Revision: https://reviews.llvm.org/D123269
rdar://91258333
rdar://31294382
(The upgrade of the ppc64le bot and D121257 have fixed compiler-rt failures. Tested by nemanjai.)
Default the option introduced in D113372 to ON to match all(?) major Linux
distros. This matches GCC and improves consistency with Android and linux-musl
which always default to PIE.
Note: CLANG_DEFAULT_PIE_ON_LINUX may be removed in the future.
Differential Revision: https://reviews.llvm.org/D120305
This matches how another similar warning is silenced in
Host/posix/ProcessLauncherPosixFork.cpp.
Differential Revision: https://reviews.llvm.org/D123205
This silences warnings like this:
lldb/source/Core/DebuggerEvents.cpp: In member function ‘llvm::StringRef lldb_private::DiagnosticEventData::GetPrefix() const’:
lldb/source/Core/DebuggerEvents.cpp:55:1: warning: control reaches end of non-void function [-Wreturn-type]
55 | }
Differential Revision: https://reviews.llvm.org/D123203
If testing for a warning option like -Wno-<foo> with GCC, GCC won't
print any diagnostic at all, leading to the options being accepted
incorrectly. However later, if compiling a file that actually prints
another warning, GCC will also print warnings about these -Wno-<foo>
options being unrecognized.
This avoids warning spam like this, for every lldb source file that
produces build warnings with GCC:
At global scope:
cc1plus: warning: unrecognized command line option ‘-Wno-vla-extension’
cc1plus: warning: unrecognized command line option ‘-Wno-deprecated-register’
This matches how such warning options are detected and added in
llvm/cmake/modules/HandleLLVMOptions.cmake, e.g. like this:
check_cxx_compiler_flag("-Wclass-memaccess" CXX_SUPPORTS_CLASS_MEMACCESS_FLAG)
append_if(CXX_SUPPORTS_CLASS_MEMACCESS_FLAG "-Wno-class-memaccess" CMAKE_CXX_FLAGS)
Differential Revision: https://reviews.llvm.org/D123202
In order to support quick arbitrary access to instructions in the trace, we need
each instruction to have an id. It could be an index or any other value that the
trace plugin defines.
This will be useful for reverse debugging or for creating callstacks, as each
frame will need an instruction id associated with them.
I've updated the `thread trace dump instructions` command accordingly. It now
prints the instruction id instead of relative offset. I've also added a new --id
argument that allows starting the dump from an arbitrary position.
Differential Revision: https://reviews.llvm.org/D122254
After enabling the LLDB index cache in production we discovered that some distributed build systems play with the modification times of any .o files that were downloaded from the build cache. This was causing the LLDB index cache to read the wrong cache file for files that didn't have a UUID as all of the modfication times were set to the same value by the build system. When new .o files were downloaded, the only unique identifier was the mod time which were all the same, and we would load an older cache for the updated .o file. So disabling caching of files that have no UUIDs for now until we can create a more solid solution.
Differential Revision: https://reviews.llvm.org/D120948
Currently, all data buffers are assumed to be writable. This is a
problem on macOS where it's not allowed to load unsigned binaries in
memory as writable. To be more precise, MAP_RESILIENT_CODESIGN and
MAP_RESILIENT_MEDIA need to be set for mapped (unsigned) binaries on our
platform.
Binaries are mapped through FileSystem::CreateDataBuffer which returns a
DataBufferLLVM. The latter is backed by a llvm::WritableMemoryBuffer
because every DataBuffer in LLDB is considered to be writable. In order
to use a read-only llvm::MemoryBuffer I had to split our abstraction
around it.
This patch distinguishes between a DataBuffer (read-only) and
WritableDataBuffer (read-write) and updates LLDB to use the appropriate
one.
rdar://74890607
Differential revision: https://reviews.llvm.org/D122856
In https://reviews.llvm.org/D118972 I increased this buffer to be
big enough to import 261,144 classes but this is a lot more than
we currently have, an allocating a too-large buffer can add memory
pressure even if it's only for a short time. Reduce the size of
this memory buffer to big enough to import 163,840 classes. I'll
probably move to a scheme where we read the objc classes in chunks,
with a smaller buffer and multiple inferior function calls.
rdar://91275493
This patch implements stderr/stdout forwarding on windows.
This was previously not implemented in D99974.
I added separate callbacks so the output can be sent to the different channels VSCode provides (OutputType::Stdout, OutputType::Stderr, OutputType::Console).
This patch also passes a log callback handler to SBDebugger::Create to be able to see logging output when it is enabled.
Since the output is now redirect on early startup I removed the calls to SetOutputFileHandle/SetErrorFileHandle, which set them to /dev/null.
I send the output of stderr/stdout/lldb log to OutputType::Console
Reviewed By: wallace
Differential Revision: https://reviews.llvm.org/D123025
Improve the documentation for the platform functions that take a process
host architecture as input.
Differential revision: https://reviews.llvm.org/D122767
Fix undefined behavior in AppleObjCRuntimeV2 where we were left shifting
a signed value. This also removes redundant casts of unobfuscated to
uint64_t which it already is.
rdar://91242879
Differential revision: https://reviews.llvm.org/D123098
When opening core files (and also in some other situations) we could end
up with two vdso modules. This could happen because the vdso module is
very special, and over the years, we have accumulated various ways to
load it.
In D10800, we added one mechanism for loading it, which took the form of
a generic load-from-memory capability. Unfortunately loading an elf file
from memory is not possible (because the loader never loads the entire
file), and our attempts to do so were causing crashes. So, in D34352, we
partially reverted D10800 and implemented a custom mechanism specific to
the vdso.
Unfortunately, enough of D10800 remained such that, under the right
circumstances, it could end up loading a second (non-functional) copy of
the vdso module. This happened when the process plugin did not support
the extended MemoryRegionInfo query (added in D22219, to workaround a
different bug), which meant that the loader plugin was not able to
recognise that the linux-vdso.so.1 module (this is how the loader calls
it) is in fact the same as the [vdso] module (the name used in
/proc/$PID/maps) we loaded before. This typically happened in a core
file, as they don't store this kind of information.
This patch fixes the issue by completing the revert of D10800 -- the
memory loading code is removed completely. It also reduces the scope of
the hackaround introduced in D22219 -- it isn't completely sound and is
only relevant for fairly old (but still supported) versions of android.
I added the memory loading logic to the wasm dynamic loader, which has
since appeared and is relying on this feature (it even has a test). As
far as I can tell loading wasm modules from memory is possible and
reliable. MachO memory loading is not affected by this patch, as it uses
a completely different code path.
Since the scenarios/patches I described came without test cases, I have
created two new gdb-client tests cases for them. They're not
particularly readable, but right now, this is the best way we can
simulate the behavior (bugs) of a particular dynamic linker.
Differential Revision: https://reviews.llvm.org/D122660
This patch handles the situation where the main thread exits (through
the SYS_exit syscall). In this case, the process as a whole continues
running until all of the other threads exit, or one of them issues an
exit_group syscall.
The patch consists of two changes:
- a moderate redesign of the handling of thread exit (WIFEXITED) events.
Previously, we were removing (forgetting) a thread once we received
the WIFEXITED (or WIFSIGNALED) event. This was problematic for the
main thread, since the main thread WIFEXITED event (which is better thought
of as a process-wide event) gets reported only after the entire process
exits. This resulted in deadlocks, where we were waiting for the
process to stop (because we still considered the main thread "live").
This patch changes the logic such that the main thread is removed as
soon as its PTRACE_EVENT_EXIT (the pre-exit) event is received. At
this point we can consider the thread gone (for most purposes). As a
corrolary, I needed to add special logic to catch process-wide exit
events in the cases where we don't have the main thread around.
- The second part of the patch is the removal of the assumptions that
the main thread is always available. This generally meant replacing
the uses of GetThreadByID(process_id) with GetCurrentThread() in
various process-wide operations (such as memory reads).
Differential Revision: https://reviews.llvm.org/D122716
About half of our host platform code was implemented in the Platform
class, while the rest was it RemoteAwarePlatform. Most of the time, this
did not matter, as nearly all our platforms are also
RemoteAwarePlatforms. It makes a difference for PlatformQemu, which
descends directly from the base class (as it is local-only).
This patch moves all host code paths into the base class, and marks
PlatformQemu as a "host" platform so it can make use of them (it sounds
slightly strange, but that is consistent with what the apple simulator
platforms are doing). Not all of the host implementations make sense for
this platform, but it can always override those that don't.
I add some basic tests using the platform file apis to exercise this
functionality.
Differential Revision: https://reviews.llvm.org/D122898
Since the threads/frame view is taking only a small part on the right side
of the screen, only a part of the function name of each frame is visible.
It seems rather wasteful to spell out 'frame' there when it's obvious
that it is a frame, it's better to use the space for more of the function
name.
Differential Revision: https://reviews.llvm.org/D122998
It's rather annoying if it's there after every startup,
and that 'Help (F6)' at the top should be enough to help people
who don't know.
Differential Revision: https://reviews.llvm.org/D122997
All uses of JSONGenerator in debugserver would create a JSON text
dump of the object collection, then copy that string into a
binary-escaped string, then send it up to the lldb side or
make a compressed version and send that.
This adds a DumpBinaryEscaped method to JSONGenerator which
does the gdb remote serial protocol binary escaping directly,
and removes the need to pass over the string and have an
additional copy in memory.
Differential Revision: https://reviews.llvm.org/D122882
rdar://91117456
The ordering is not needed, and DenseMap is faster. I can measure
time spent in the SaveToCache() calls reduced to ~40% during LLDB
startup (and the total startup cost reduced to ~70%).
Differential Revision: https://reviews.llvm.org/D122980
The current design allows that the object file contents could be mapped
by one object file plugin and then used by another. Presumably the idea
here was to avoid mapping the same file twice.
This becomes an issue when one object file plugin wants to map the file
differently from the others. For example, ObjectFileELF needs to map its
memory as writable while others likeObjectFileMachO needs it to be
mapped read-only.
This patch prevents plugins from changing the buffer by passing them is
by value rather than by reference.
Differential revision: https://reviews.llvm.org/D122944
Environments are optional and a missing environment is distinct from
the default "unknown" environment enumerator. The test is negative,
because the function uses the host triple and is unpredictable.
rdar://91007207
https://reviews.llvm.org/D122946
Differential Revision: https://reviews.llvm.org/D122946
This updates the disassembler to enable every optional extension.
Previously we had added things that we added "support" for in lldb.
(where support means significant work like new registers, fault types, etc.)
Something like TME (transactional memory) wasn't added because
there are no new lldb features for it. However we should still be
disassembling the instructions.
So I went through the AArch64 extensions and added all the missing
ones. The new test won't prevent us missing a new extension but it
does at least document our current settings.
Reviewed By: labath
Differential Revision: https://reviews.llvm.org/D121999
It is the PC line, selected or not, that gets the blue-background
highlight. Without this, a keyword like 'bool' got black background
if the line wasn't selected.
And the blue-background highlight is handled by OutputColoredStringTruncated(),
so no point in setting it explicitly in the calling code.
A problem that I introduced in the decoder is that I was considering TSC decoding
errors as actual instruction errors, which mean that the trace has a gap. This is
wrong because a TSC decoding error doesn't mean that there's a gap in the trace.
Instead, now I'm just counting how many of these errors happened and I'm using
the `dump info` command to check for this number.
Besides that, I refactored the decoder a little bit to make it simpler, more
readable, and to handle TSCs in a cleaner way.
Differential Revision: https://reviews.llvm.org/D122867
Update the Linux and NetBSD Host libraries for 2165c36be4 which
removed DataBufferLLVM::GetChars. These files are compiled conditionally
based on the host platform.
I found this function somewhat hard to read and removed a few entirely
redundant checks and converted it to early exits.
Differential Revision: https://reviews.llvm.org/D122912
This creates inline functions decls in the TUs where the funcitons are inlined and local variable decls inside those functions.
Reviewed By: labath
Differential Revision: https://reviews.llvm.org/D121967
Storing timestamps (TSCs) in a more efficient map at the decoded thread level to speed up TSC lookup, as well as reduce the amount of memory used by each decoded instruction. Also introduced TSC range which keeps the current timestamp valid for all subsequent instructions until the next timestamp is emitted.
Differential Revision: https://reviews.llvm.org/D122603
Many callers of SendPacket() in RNBRemote.cpp have a local std::string
object, call c_str() on it to pass a c-string, which is then copied into
a std::string temporary object.
Also free JSONGenerator objects once we've formatted them into
ostringstream and don't need the objects any longer, to reduce max
memory use in debugserver.
Differential Revision: https://reviews.llvm.org/D122848
rdar://91117263
Protecting against accidental overwriting of commands is good, but
having to pass a flag to overwrite the command when developing your
commands is pretty annoying. This adds a setting to defeat the protection
so you can do this once at the start of your session and not have to
worry about it again.
Differential Revision: https://reviews.llvm.org/D122680
Applied modernize-use-equals-default clang-tidy check over LLDB.
This check is already present in the lldb/.clang-tidy config.
Differential Revision: https://reviews.llvm.org/D121844
NSIndexPathSyntheticFrontEnd::Impl::Clear() currently calls Clear() on both
unions members regardless of which one is active. I modified it to only call
Clear() on the active member.
Differential Revision: https://reviews.llvm.org/D122753
Currently, when creating a target for a fat binary, we error out if more
than one platforms can support the different architectures in the
binary. There are situations where it makes sense for multiple platforms
to support the same architectures: for example the host and
remote-macosx platform on Darwin.
The only way to currently disambiguate between them is to specify the
architecture. This patch changes that to take into account the selected
and host platform. The new algorithm works a follows:
1. Pick the selected platform if it matches any of the architectures.
2. Pick the host platform if it matches any of the architectures.
3. If there's one platform that works for all architectures, pick that.
If none of the above apply then we either have no platform supporting
the architectures in the fat binary or multiple platforms with no good
way to disambiguate between them.
I've added a bunch of unit tests to codify this new behavior.
rdar://90360204
Differential revision: https://reviews.llvm.org/D122684
This recommits dddf4ce03, which was reverted because of a couple of test
failures on macos. The reason behind the failures was that the patch
inadvertenly changed the value returned by the host platform from
"macosx" to "darwin". The new version fixes that.
Original commit message was:
The decision which categories are relevant for a particular test run
happen very early in the test setup process. They use the SBPlatform
object to determine which categories should be skipped. The platform
object created for this purpose transcends individual test runs.
This setup is not compatible with the direction discussed in
<https://discourse.llvm.org/t/multiple-platforms-with-the-same-name/59594>
-- when platform objects are tied to a specific (SB)Debugger, they need
to be created alongside it, which currently happens in the test setUp
method.
This patch is the first step in that direction -- it rewrites the
category skipping logic to avoid depending on a global SBPlatform
object. Fortunately, the skipping logic is fairly simple (and I believe
it outght to stay that way) and mainly consists of comparing the
platform name against some hardcoded lists. This patch bases this
comparison on the platform name instead of the os part of the triple (as
reported by the platform).
Differential Revision: https://reviews.llvm.org/D121605
lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.cpp:472:16: warning: enumeration value 'HLSL' not handled in switch [-Wswitch]
switch (IK.getLanguage()) {
^
Some signal handlers were set up within an !_MSC_VER condition,
i.e. omitted in MSVC builds but included in mingw builds. Previously
sigtstp_handler was defined in all builds, but since
4bcadd6686 / D120320 it's only
defined non platforms other than Windows.
Change the condition to !_WIN32 for consistency between the MSVC
and mingw builds, fixing the build for mingw.
Differential Revision: https://reviews.llvm.org/D122486
Now the decoded thread has Append methods that provide more flexibility
in terms of the underlying data structure that represents the
instructions. In this case, we are able to represent the sporadic errors
as map and thus reduce the size of each instruction.
Differential Revision: https://reviews.llvm.org/D122293
With the shared cache getting split into multiple files, the current
way we created ObjectFileMachO objects for shared cache dylib images
will break.
This patch conditionally adopts new SPIs which will do the right
thing in the new world of multi-file caches.
With Scripted Processes, in order to create scripted threads, the blueprint
provides a dictionary that have each thread index as the key with the respective
thread instance as the pair value.
In Python, this is fine because a dictionary key can be of any type including
integer types:
```
>>> {1: "one", 2: "two", 10: "ten"}
{1: 'one', 2: 'two', 10: 'ten'}
```
However, when the python dictionary gets bridged to C++ we convert it to a
`StructuredData::Dictionary` that uses a `std::map<ConstString, ObjectSP>`
for storage.
Because `std::map` is an ordered container and ours uses the `ConstString`
type for keys, the thread indices gets converted to strings which makes the
dictionary sorted alphabetically, instead of numerically.
If the ScriptedProcess has 10 threads or more, it causes thread “10”
(and higher) to be after thread “1”, but before thread “2”.
In order to solve this, this sorts the thread info dictionary keys
numerically, before iterating over them to create ScriptedThreads.
rdar://90327854
Differential Revision: https://reviews.llvm.org/D122429
Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
This patch changes `StructuredData::Dictionary::GetKeys` return type
from an `StructuredData::ObjectSP` to a `StructuredData::ArraySP`.
The function already stored the keys in an array but implicitely upcasted
it to an `ObjectSP`, which required the user to convert it again to a
Array object to access each element.
Since we know the keys should be held by an iterable container, it makes
more sense to return the allocated ArraySP as-is.
Differential Revision: https://reviews.llvm.org/D122426
Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
Previously, the ScriptedThread used the thread index as the thread id.
This patch parses the crashlog json to extract the actual thread "id" value,
and passes this information to the Crashlog ScriptedProcess blueprint,
to create a higher fidelity ScriptedThreaad.
It also updates the blueprint to show the thread name and thread queue.
Finally, this patch updates the interactive crashlog test to reflect
these changes.
rdar://90327854
Differential Revision: https://reviews.llvm.org/D122422
Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
Fixes "Cannot specify link libraries for target "lldb-target-fuzzer"
which is not built by this project." Normally that's taken care of by
add_llvm_fuzzer but we need target_link_libraries for liblldb and our
utility library.
This patch adds a generic fuzzer that interprets inputs as object files
and uses them to create a target in lldb. It is very similar to the
llvm-dwarfdump fuzzer which found a bunch of issues in libObject.
Differential revision: https://reviews.llvm.org/D122461
When iterating over all Platforms looking for the best one, on a Mac the
Simulator platforms (iOS, tvOS, watchOS) will first find their SDK
directory by calling xcrun, then decide if they should activate or not.
When that SDK is absent, the call to xcrun to find it can be very slow.
This patch delays that directory search until we know we're activating
this platform, so non-simulator environments don't pay a perf cost ever
time they go through the list of platforms.
Differential Revision: https://reviews.llvm.org/D122373
rdar://87960090
Update the response schema of the TraceGetState packet and add
Intel PT specific response structure that contains the TSC conversion,
if it exists. The IntelPTCollector loads the TSC conversion and caches
it to prevent unnecessary calls to perf_event_open. Move the TSC conversion
calculation from Perf.h to TraceIntelPTGDBRemotePackets.h to remove
dependency on Linux specific headers.
Differential Revision: https://reviews.llvm.org/D122246
This patch adds a test for b0dc2fae60. That commit fixed a bug where
we could increment the indirect symbol offset every time we parsed the
symbol table.
In ProcessMachCore::DoLoadCore when we have a standalone
binary and a 'main bin spec' LC_NOTE detailing the UUID and
load address, ProcessMachCore will do a (potentially slow)
lookup to try to find the binary and/or dSYM. For kernel and
userland corefile using 'main bin spec', we would follow the
normal schemes of locating them. DynamicLoaderDarwinKernel would
use the same (possibly expensive) calls to find the correct
binary. dyld by default would use the in-core-file binary image,
and so if the corefile didn't include the entire address space,
the LINKEDIT for dyld could be missing. This means we can't find
the dyld4::dyld_all_image_infos struct, which tells us where the
other binaries are loaded in memory.
Treat userland 'bin main spec' like we do standalone firmewares;
try the expensive checks to find the best dyld we can, before
falling back to using a memory module out of the corefile.
Also add a little TODO for myself in this load_standalone_binary
function that we should handle the case of a binary in the shared
cache correctly, creating a memory module in the corefile and
using the segment load addresses from that to set our segment
load addresses for the final binary.
rdar://89717101
The current code increment the indirect symbol offset with the LINKEDIT
slide every time ObjectFileMachO::ParseSymtab is called.
This resulted in a crash when calling add-dsym which causes us to
potentially re-parse the original binary's symbol table. There's a
separate question about whether we should re-parse the symbol table at
all which was fixed by D114288. Regardless, copying the load command is
cheap enough that this is still the right thing to do.
rdar://72337717
Differential revision: https://reviews.llvm.org/D122349
The assertion checks that the command output doesn't contain any null
bytes. I'm not sure if the intention was to make sure the string wasn't
shorter than the reported length or if this was a way to catch us
accidentally writing an (unformatted) null byte.
The consensus is that we don't want to have embedded nulls in the
command output, but that this isn't the right place to enforce that.
Differential revision: https://reviews.llvm.org/D122025
This patch introduces 2 new lldb utility functions:
- lldbutil.start_listening_from: This can be called in the test setup to
create a listener and set it up for a specific event mask and add it
to the user-provided broadcaster's list.
- lldbutil.fetch_next_event: This will use fetch a single event from the
provided istener and return it if it matches the provided broadcaster.
The motivation behind this is to easily test new kinds of events
(i.e. Swift type-system progress events). However, this patch also
updates `TestProgressReporting.py` and `TestDiagnosticReporting.py`
to make use of these new helper functions.
Differential Revision: https://reviews.llvm.org/D122193
Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
Avoid "TERM environment variable not set" by either propagating the TERM
environment variable or defaulting to vt100. All of our CI is already
doing this explicitly through the --env dotest arg, but it's easy to
forget when setting up a new job. I don't see any downside in making it
the default.
By default these timeouts are extremely small (0.1s). This means that
100ms after sending an EOF, pexpect will start sending the process
increasingly aggressive signals, but the small timeouts mean that (on a
loaded machine) the kernel may not have enough time to process the
signal even if the overall effect of the signal is to kill the
application.
It turns out we were already relying on this signals (instead of regular
EOF quits) in our tests. In my experiments it was sufficient to block
SIGINT and SIGHUP to cause some test to become flaky. This was most
likely the reason of a couple of flakes on the lldb-x86_64-debian bot,
and is probably the reason why the pexpect tests are flaky on several
other (e.g. asan) bots.
This patch increses the timeout to 6 seconds (60-fold increase), which
is hopefully sufficient to avoid flakes even in the most extreme
situations.
There's a bug caused when a process is relaunched: the target, which
doesn't change, keeps the Trace object from the previous process, which
is already defunct, and causes segmentation faults when it's attempted
to be used.
A fix is to clean up the Trace object when the target is disposing of
the previous process during relaunches.
A way to reproduce this:
```
lldb a.out
b main
r
process trace start
c
r
process trace start
```
Differential Revision: https://reviews.llvm.org/D122176
I incorrectly returned an ArrayRef when the underlying object didn't own
the data. Instead, returning a vector<uint8_t> is what we should do.
This fixes an issue when trying to access an intel-pt trace buffer
larger than 16 MB.
repro
```
go to a breakpoint
thread trace start -s 16777216
n
thread trace dump instructions # this doesn't fail anymore
```
Differential Revision: https://reviews.llvm.org/D122192
Fix the log and progress report message for in-memory binaries. If
there's no object file, use the name from the Module. With this patch we
correctly show the library name when attaching to a remote process
without an expanded shared cache.
Differential revision: https://reviews.llvm.org/D122177
- Add PerfEvent class to handle creating ring buffers and handle the resources associated with a perf_event
- Refactor IntelPT collection code to use this new API
- Add TSC to timestamp conversion logic with unittest
Differential Revision: https://reviews.llvm.org/D121734
Added a line to `thread trace dump info` results which shows total number of instructions executed until now.
Differential Revision: https://reviews.llvm.org/D122076
This patch introduces a generic helper class that will listen for
event in a background thread and match it against a source broadcaster.
If the event received matches the source broadcaster, the event is
queued up in a list that the user can access later on.
The motivation behind this is to easily test new kinds of events
(i.e. Swift type-system progress events). However, this patch also
updates `TestProgressReporting.py` and `TestDiagnosticReporting.py`
to make use of this new helper class.
Differential Revision: https://reviews.llvm.org/D121977
Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
Minor fixes needed and now `./bin/lldb-dotest -p TestTrace` passes
correctly.
- There was an incorrect iteration.
- Some error messages changed.
- The way repeat commands are handled changed a bit, so I had to create
a new --continue arg in "thread trace dump instructions" to handle this
correctly.
Differential Revision: https://reviews.llvm.org/D122023
On darwin, we don't completely suppress the signal used to interrupt the
inferior. The underlying read syscall returns EINTR, which causes premature
termination of the input loop.
Work around that by hand-rolling an EINTR-resistant version of getline.
D120762 accidentally moved the interrupt check into the block which was
reading stdio. This meant that a ^C only took effect after a regular
character has been pressed.
This patch fixes that and adds a (pexpect) test.
Differential Revision: https://reviews.llvm.org/D121912
The call is useless, as any modules loaded there will be removed in
ResolveExecutableModule. Modules will be reloaded again through the
GetLoadedModuleList call in DYLDRendezvous.cpp.
D120762 accidentally moved the interrupt check into the block which was
reading stdio. This meant that a ^C only took effect after a regular
character has been pressed.
This patch fixes that and adds a (pexpect) test.
Differential revision: https://reviews.llvm.org/D121912
MakeLoadImageUtilityFunction() is not using extern "C" for external C functions
and it is not using eLanguageTypeC_plus_plus. So I am modifying it to be consistent.
Also see: rdar://87544782
Differential Revision: https://reviews.llvm.org/D121831
Migrate to using ReportError to report a failure to evaluate a
watchpoint condition. I had already done so for the parallel code for
breakpoints.
In the process, I noticed that I accidentally regressed the error
reporting for breakpoint conditions by dropping the call to
GetDescription. This patch rectifies that and adds a test.
Because the call to GetDescription expects a Stream*, I also switches
from using a raw_string_ostream to a StreamString for both breakpoints
and watchpoints.
This patch pipes down the `-a|--load-all` crashlog command option to the
Scripted Process initializer to load all the images used by crashed
process instead of only loading the images related to the crashed
thread.
This allows us to recreate artificial frames also for the non-crashed
scripted threads.
rdar://90396265
Differential Revision: https://reviews.llvm.org/D121826
Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
- Rename IntelPTManager class and files to IntelPTCollector
- Change GetTimestampCounter API to general trace counter API,
GetCounter
Differential Revision: https://reviews.llvm.org/D121711
Expose diagnostic events through the SB API. Unlike the progress events,
I opted to use a SBStructuredData so that we can add fields in the
future.
Differential revision: https://reviews.llvm.org/D121818
Commit 3251ba2d0f ("[Attr] Fix a btf_type_tag AST generation")
added a new type BTFTagAttributedType to the clang AST type
system. There are a few places in lldb needed to handle this type
similar to Attributed type to avoid compilation warning/error
when 'switch' is used to enumerate all types.
Report warnings and errors through events instead of printing directly
the to the debugger's error stream. By using events, IDEs such as Xcode
can report these issues in the UI instead of having them show up in the
debugger console.
The new diagnostic events are handled by the default event loop. If a
diagnostic is reported while nobody is listening for the new event
types, it is printed directly to the debugger's error stream.
Differential revision: https://reviews.llvm.org/D121511
The log channel was changed from Types to Commands in
a007a6d84471bb956abe10974cac3066799f583f:
- Log *log(GetLogIfAllCategoriesSet(LIBLLDB_LOG_PROCESS | LIBLLDB_LOG_TYPES));
+ Log *log = GetLog(LLDBLog::Process | LLDBLog::Commands);
`UdtRecordCompleter` shouldn't complete static members' types. static members' types are going to be completed when the types are called in `SymbolFile::CompleteType`.
Reviewed By: labath
Differential Revision: https://reviews.llvm.org/D121030
Add synchronization to the IOHandler to prevent multiple threads from
writing concurrently to the output or error stream.
A scenario where this could happen is when a thread (the default event
thread for example) is using the debugger's asynchronous stream. We
would delegate this operation to the IOHandler which might be running on
another thread. Until this patch there was nothing to synchronize the
two at the IOHandler level.
Differential revision: https://reviews.llvm.org/D121500
This reverts commit 242c574dc0 because it
breaks the following tests on the bots:
- TestGuiExpandThreadsTree.py
- TestBreakpointCallbackCommandSource.py
Currently DW_OP_deref_size just drops the ValueType::FileAddress case and does
not attempt to handle it. This adds support for this case and a test that
verifies this support.
I did a little refactoring since DW_OP_deref and DW_OP_deref_size have some
overlap in code.
Also see: rdar://66870821
Differential Revision: https://reviews.llvm.org/D121408
I thought that x86GetSupportedArchitectures would always return
x86_64-apple-macosx as a compatible architecture, regardless of the host
achitecture, but the Debian bot disagrees with that.
Add synchronization to the IOHandler to prevent multiple threads from
writing concurrently to the output or error stream.
A scenario where this could happen is when a thread (the default event
thread for example) is using the debugger's asynchronous stream. We
would delegate this operation to the IOHandler which might be running on
another thread. Until this patch there was nothing to synchronize the
two at the IOHandler level.
Differential revision: https://reviews.llvm.org/D121500
This patch is another attempt to fix platform selection on Apple
Silicon. It partially undoes D117340 which tried to fix the issue by
always instantiating a remote-ios platform for "iPhone and iPad Apps on
Apple Silicon Macs".
While the previous patch worked for attaching, it broke launching and
everything else that expects the remote platform to be connected. I made
an attempt to work around that, but quickly found out that there were
just too may places that had this assumption baked in.
This patch takes a different approach and reverts back to marking the
host platform compatible with iOS triples. This brings us back to the
original situation where platform selection was broken for remote iOS
debugging on Apple Silicon. To fix that, we now look at the process'
host architecture to differentiate between iOS binaries running remotely
and iOS binaries running locally.
I tested the following scenarios, which now all uses the desired
platform:
- Launching an iOS binary on macOS: uses the host platform
- Attaching to an iOS binary on macOS: uses the host platform
- Attaching to a remote iOS binary: uses the remote-ios platform
rdar://89840215
Differential revision: https://reviews.llvm.org/D121444
The decision which categories are relevant for a particular test run
happen very early in the test setup process. They use the SBPlatform
object to determine which categories should be skipped. The platform
object created for this purpose transcends individual test runs.
This setup is not compatible with the direction discussed in
<https://discourse.llvm.org/t/multiple-platforms-with-the-same-name/59594>
-- when platform objects are tied to a specific (SB)Debugger, they need
to be created alongside it, which currently happens in the test setUp
method.
This patch is the first step in that direction -- it rewrites the
category skipping logic to avoid depending on a global SBPlatform
object. Fortunately, the skipping logic is fairly simple (and I believe
it outght to stay that way) and mainly consists of comparing the
platform name against some hardcoded lists. This patch bases this
comparison on the platform name instead of the os part of the triple (as
reported by the platform).
Differential Revision: https://reviews.llvm.org/D121605
While working on dde487e547 I noticed that the MacOSX platforms were
in need of some love. This patch cleans up the headers:
- Move platforms into the lldb_private namespace.
- Remove lldb_private:: prefixes to improve readability.
- Fix header includes and use forward declarations (iwyu).
- Fix formatting
They don't require that the memory return address be restored prior to
function exit, so there's no guarantee the value is correct. It's better
to return nothing that something that's not accurate.
Differential Revision: https://reviews.llvm.org/D121348
Applied modernize-use-default-member-init clang-tidy check over LLDB.
It appears in many files we had already switched to in class member init but
never updated the constructors to reflect that. This check is already present in
the lldb/.clang-tidy config.
Differential Revision: https://reviews.llvm.org/D121481
To allow us to select a different platform based on where the process is
running, plumb the process host architecture through platform selection.
This patch is in preparation for D121444 which needs this functionality
to tell apart iOS binaries running on Apple Silicon vs on a remote iOS
device.
Differential revision: https://reviews.llvm.org/D121484
The rest of LLVM uses `print` for the method taking the `raw_ostream`
and `dump` only for the method with no parameters. Use the same for
`RedirectingFileSystem`.
Differential Revision: https://reviews.llvm.org/D121494
Use the debugger's asynchronous output stream for printing progress
events. This allows the active IOHandler to be in charge of printing
them and doing the necessary synchronization.
Differential revision: https://reviews.llvm.org/D121502
PrintAsync is relying on the IOHandler to print to the output/error
stream. In that context it doesn't make much sense that this is using
the debugger's streams rather than the one from the IOHandler.
Differential revision: https://reviews.llvm.org/D121536
Move ProgressEventData out of debugger and into its own file. This is in
preparation of adding a few new type of event data for diagnostics.
Differential revision: https://reviews.llvm.org/D121506
Jonas Devlieghere