Do not send SIGSTOP when requested to halt a process that's already
stopped. This results in the signal being queued for delivery once
the process is resumed, and unexpectedly stopping it again.
This is necessary for non-stop protocol patches to land.
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.llvm.org/D126770
On Ubuntu 18.04 with GCC 7.5 Intel trace code fails to build due to
failure to convert from
lldb_private::process_linux::IntelPTPerThreadProcessTraceUP to
Expected<lldb_private::process_linux::IntelPTPerThreadProcessTraceUP>.
This commit explicitely marks those unique_ptr values as being moved
which fixes the conversion error.
Reviewed By: wallace
Differential Revision: https://reviews.llvm.org/D126402
should not receive as exceptions (some will get converted to BSD
signals instead). This is really the only stable way to ensure that
a Mach exception gets converted to it's equivalent BSD signal. For
programs that rely on BSD signal handlers, this has to happen or you
can't even get the program to invoke the signal handler when under
the debugger.
This builds on a previous solution to this problem which required you
start debugserver with the -U flag. This was not very discoverable
and required lldb be the one to launch debugserver, which is not always
the case.
Differential Revision: https://reviews.llvm.org/D125434
Previously if you read a code/data mask before there was a valid thread
you would get the top byte mask. This meant the value was "valid" as in,
don't read it again.
When using a corefile we ask for the data mask very early on and this
meant that later once you did have a thread it wouldn't read the
register to get the rest of the mask.
This fixes that and adds a corefile test generated from the same program
as in my previous change on this theme.
Depends on D118794
Reviewed By: omjavaid
Differential Revision: https://reviews.llvm.org/D122411
IntelPTCollector is very big and has 3 classes in it. It's actually cleaner if each one has its own file. This also gives more visibility to the developer about the different kinds of "tracers" that we have.
Besides that, I'm now restricting the creation of the BinaryData chunks to GetState() instead of having it in different places, which is not very clean, because the gdb-remote protocol should be as restricted as possible.
Differential Revision: https://reviews.llvm.org/D125047
When tracing on per-core mode, we are tracing all processes, which means
that after hitting a breakpoint, our process will stop running (thus
producing no more tracing data) but other processes will continue
writing to our trace buffers. This causes a big data loss for our trace.
As a way to remediate this, I'm adding some logic to pause and unpause
tracing based on the target's state. The earlier we do it the better,
however, I'm not adding the trigger at the earliest possible point for
simplicity of this diff. Later we can improve that part.
Differential Revision: https://reviews.llvm.org/D124962
This diffs implements per-core tracing on lldb-server. It also includes tests that ensure that tracing can be initiated from the client and that the jLLDBGetState ppacket returns the list of trace buffers per core.
This doesn't include any decoder changes.
Finally, this makes some little changes here and there improving the existing code.
A specific piece of code that can't reliably be tested is when tracing
per core fails due to permissions. In this case we add a
troubleshooting message and this is the manual test:
```
/proc/sys/kernel/perf_event_paranoid set to 1
(lldb) process trace start --per-core-tracing error: perf event syscall failed: Permission denied
You might need that /proc/sys/kernel/perf_event_paranoid has a value of 0 or -1.
``
Differential Revision: https://reviews.llvm.org/D124858
llvm's json parser supports uint64_t, so let's better use it for the
packets being sent between lldb and lldb-server instead of using int64_t
as an intermediate type, which might be error-prone.
llvm's json parser supports uint64_t, so let's better use it for the
packets being sent between lldb and lldb-server instead of using int64_t
as an intermediate type, which might be error-prone.
I'm refactoring IntelPTThreadTrace into IntelPTSingleBufferTrace so that it can
both single threads or single cores. In this diff I'm basically renaming the
class, moving it to its own file, and removing all the pieces that are not used
along with some basic cleanup.
Differential Revision: https://reviews.llvm.org/D124648
This updates the documentation of the gdb-remote protocol, as well as the help messages, to include the new --per-core-tracing option.
Differential Revision: https://reviews.llvm.org/D124640
In order to open perf events per core, we need to first get the list of
core ids available in the system. So I'm adding a function that does
that by parsing /proc/cpuinfo. That seems to be the simplest and most
portable way to do that.
Besides that, I made a few refactors and renames to reflect better that
the cpu info that we use in lldb-server comes from procfs.
Differential Revision: https://reviews.llvm.org/D124573
Applied clang-tidy modernize-use-override over LLDB and added it to the LLDB .clang-tidy config.
Differential Revision: https://reviews.llvm.org/D123340
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
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
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
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
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>
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
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
- 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
- Rename IntelPTManager class and files to IntelPTCollector
- Change GetTimestampCounter API to general trace counter API,
GetCounter
Differential Revision: https://reviews.llvm.org/D121711
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
This patch adds a getter for the process' system architecture. I went
with Process::GetSystemArchitecture to match
Platform::GetSystemArchitecture.
Differential revision: https://reviews.llvm.org/D121443
Don't overwrite the host architecture (obtained from qHostInfo) with the
process info (obtained from qProcessInfo).
Differential revision: https://reviews.llvm.org/D121442
This workaround is the source of an awkwared Process->Platform
dependency. While this could be solved in various ways (the only thing
we really use is the plugin name), it may be better to just remove it --
the workaround was added 10 years ago (43c555dfc), and the affected
debugservers were "old" even then, so hopefully they are not in use
anymore.
Differential Revision: https://reviews.llvm.org/D121305
This patch introduces a new way to load modules programatically with
Scripted Processes. To do so, the scripted process blueprint holds a
list of dictionary describing the modules to load, which their path or
uuid, load address and eventually a slide offset.
LLDB will fetch that list after launching the ScriptedProcess, and
iterate over each entry to create the module that will be loaded in the
Scripted Process' target.
The patch also refactors the StackCoreScriptedProcess test to stop
inside the `libbaz` module and make sure it's loaded correctly and that
we can fetch some variables from it.
rdar://74520238
Differential Revision: https://reviews.llvm.org/D120969
Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
This patch replaces the calls to ErrorWithMessage using the GetInterface
message by a call to the static method directly.
Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
This patch changes the return value of Platform::GetName() to a
StringRef, and uses the opportunity (compile errors) to change some
callsites to use GetPluginName() instead. The two methods still remain
hardwired to return the same thing, but this will change once the ideas
in
<https://discourse.llvm.org/t/multiple-platforms-with-the-same-name/59594>
are implemented.
Differential Revision: https://reviews.llvm.org/D119146
All current callers set the argument to false. monitor_signals=true used
to be used in the Process plugins (which needed to know when the
debugged process gets a signal), but this implementation has several
serious issues, which means that individual process plugins now
orchestrate the monitoring of debugged processes themselves.
This allows us to simplify the implementation (no need to play with
process groups), and the interface (we only catch fatal events, so the
callback is always called just once).
Differential Revision: https://reviews.llvm.org/D120425
