[lldb-server/linux] Use waitpid(-1) to collect inferior events

This is a follow-up to D116372, which had a rather unfortunate side
effect of making the processing of a single SIGCHLD quadratic in th

[lldb-server/linux] Use waitpid(-1) to collect inferior events

This is a follow-up to D116372, which had a rather unfortunate side
effect of making the processing of a single SIGCHLD quadratic in the
number of threads -- which does not matter for simple applications, but
can get really bad for applications with thousands of threads.

This patch fixes the problem by implementing the other possibility
mentioned in the first patch -- doing waitpid(-1) centrally and then
routing the events to the correct process instance. The "uncollected"
threads are held in the process factory class -- which I've renamed to
Manager for this purpose, as it now does more than creating processes.

Differential Revision: https://reviews.llvm.org/D146977

show more ...

[trace][intelpt] Support system-wide tracing [9] - Collect and return context switch traces

- Add collection of context switches per cpu grouped with the per-cpu intel pt traces.
- Move the state ha

[trace][intelpt] Support system-wide tracing [9] - Collect and return context switch traces

- Add collection of context switches per cpu grouped with the per-cpu intel pt traces.
- Move the state handling from the interl pt trace class to the PerfEvent one.
- Add support for stopping and enabling perf event groups.
- Return context switch entries as part of the jLLDBTraceGetState response.
- Move the triggers of whenever the process stopped or resumed. Now the will-resume notification is in a better location, which will ensure that we'll capture the instructions that will be executed.
- Remove IntelPTSingleBufferTraceUP. The unique pointer was useless.
- Add unit tests

Differential Revision: https://reviews.llvm.org/D125897

show more ...

[trace][intelpt] Support system-wide tracing [5] - Disable/enable per-core tracing based on the process state

When tracing on per-core mode, we are tracing all processes, which means
that after hitt

[trace][intelpt] Support system-wide tracing [5] - Disable/enable per-core tracing based on the process state

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

show more ...

Minor refactor and renaming:
- Rename IntelPTManager class and files to IntelPTCollector
- Change GetTimestampCounter API to general trace counter API,
GetCounter

Differential Revision: http

Minor refactor and renaming:
- Rename IntelPTManager class and files to IntelPTCollector
- Change GetTimestampCounter API to general trace counter API,
GetCounter

Differential Revision: https://reviews.llvm.org/D121711

show more ...

[lldb] [llgs] Implement qXfer:siginfo:read

Implement the qXfer:siginfo:read that is used to read the siginfo_t
(extended signal information) for the current thread. This is currently
implemented on

[lldb] [llgs] Implement qXfer:siginfo:read

Implement the qXfer:siginfo:read that is used to read the siginfo_t
(extended signal information) for the current thread. This is currently
implemented on FreeBSD and Linux.

Differential Revision: https://reviews.llvm.org/D117113

show more ...

[lldb-server/linux] Fix waitpid for multithreaded forks

The lldb-server code is currently set up in a way that each
NativeProcess instance does its own waitpid handling. This works fine
for BSDs, wh

[lldb-server/linux] Fix waitpid for multithreaded forks

The lldb-server code is currently set up in a way that each
NativeProcess instance does its own waitpid handling. This works fine
for BSDs, where the code can do a waitpid(process_id), and get
information for all threads in that process.

The situation is trickier on linux, because waitpid(pid) will only
return information for the main thread of the process (one whose tid ==
pid). For this reason the linux code does a waitpid(-1), to get
information for all threads. This was fine while we were supporting just
a single process, but becomes a problem when we have multiple processes
as they end up stealing each others events.

There are two possible solutions to this problem:
- call waitpid(-1) centrally, and then dispatch the events to the
appropriate process
- have each process call waitpid(tid) for all the threads it manages

This patch implements the second approach. Besides fitting better into
the existing design, it also has the added benefit of ensuring
predictable ordering for thread/process creation events (which come in
pairs -- one for the parent and one for the child). The first approach
OTOH, would make this ordering even more complicated since we would
have to keep the half-threads hanging in mid-air until we find the
process we should attach them to.

The downside to this approach is an increased number of syscalls (one
waitpid for each thread), but I think we're pretty far from optimizing
things like this, and so the cleanliness of the design is worth it.

The included test reproduces the circumstances which should demonstrate
the bug (which manifests as a hung test), but I have not been able to
get it to fail. The only place I've seen this failure modes are very
rare hangs in the thread sanitizer tests (tsan forks an addr2line
process to produce its error messages).

Differential Revision: https://reviews.llvm.org/D116372

show more ...

[lldb/linux] Fix a bug in wait status handling

The MonitorCallback function was assuming that the "exited" argument is
set whenever a thread exits, but the caller was only setting that flag
for the

[lldb/linux] Fix a bug in wait status handling

The MonitorCallback function was assuming that the "exited" argument is
set whenever a thread exits, but the caller was only setting that flag
for the main thread.

This patch deletes the argument altogether, and lets MonitorCallback
compute what it needs itself.

This is almost NFC, since previously we would end up in the
"GetSignalInfo failed for unknown reasons" branch, which was doing the
same thing -- forgetting about the thread.

show more ...

[lldb][AArch64] Add memory tag writing to lldb-server

This is implemented using the QMemTags packet, as specified
by GDB in:
https://sourceware.org/gdb/current/onlinedocs/gdb/General-Query-Packets.h

[lldb][AArch64] Add memory tag writing to lldb-server

This is implemented using the QMemTags packet, as specified
by GDB in:
https://sourceware.org/gdb/current/onlinedocs/gdb/General-Query-Packets.html#General-Query-Packets

(recall that qMemTags was previously added to read tags)

On receipt of a valid packet lldb-server will:
* align the given address and length to granules
(most of the time lldb will have already done this
but the specification doesn't guarantee it)
* Repeat the supplied tags as many times as needed to cover
the range. (if tags > range we just use as many as needed)
* Call ptrace POKEMTETAGS to write the tags.

The ptrace step will loop just like the tag read does,
until all tags are written or we get an error.
Meaning that if ptrace succeeds it could be a partial write.
So we call it again and if we then get an error, return an error to
lldb.

We are not going to attempt to restore tags after a partial
write followed by an error. This matches the behaviour of the
existing memory writes.

The lldb-server tests have been extended to include read and
write in the same test file. With some updated function names
since "qMemTags" vs "QMemTags" isn't very clear when they're
next to each other.

Reviewed By: omjavaid

Differential Revision: https://reviews.llvm.org/D105180

show more ...

[lldb][AArch64] Add memory tag reading to lldb-server

This adds memory tag reading using the new "qMemTags"
packet and ptrace on AArch64 Linux.

This new packet is following the one used by GDB.
(ht

[lldb][AArch64] Add memory tag reading to lldb-server

This adds memory tag reading using the new "qMemTags"
packet and ptrace on AArch64 Linux.

This new packet is following the one used by GDB.
(https://sourceware.org/gdb/current/onlinedocs/gdb/General-Query-Packets.html)

On AArch64 Linux we use ptrace's PEEKMTETAGS to read
tags and we assume that lldb has already checked that the
memory region actually has tagging enabled.

We do not assume that lldb has expanded the requested range
to granules and expand it again to be sure.
(although lldb will be sending aligned ranges because it happens
to need them client side anyway)
Also we don't assume untagged addresses. So for AArch64 we'll
remove the top byte before using them. (the top byte includes
MTE and other non address data)

To do the ptrace read NativeProcessLinux will ask the native
register context for a memory tag manager based on the
type in the packet. This also gives you the ptrace numbers you need.
(it's called a register context but it also has non register data,
so it saves adding another per platform sub class)

The only supported platform for this is AArch64 Linux and the only
supported tag type is MTE allocation tags. Anything else will
error.

Ptrace can return a partial result but for lldb-server we will
be treating that as an error. To succeed we need to get all the tags
we expect.

(Note that the protocol leaves room for logical tags to be
read via qMemTags but this is not going to be implemented for lldb
at this time.)

Reviewed By: omjavaid

Differential Revision: https://reviews.llvm.org/D95601

show more ...

[lldb] [Process/Linux] Report fork/vfork stop reason

Enable reporting fork/vfork events to the server when supported.
At this moment, this is used only to test the server code, as real
client does n

[lldb] [Process/Linux] Report fork/vfork stop reason

Enable reporting fork/vfork events to the server when supported.
At this moment, this is used only to test the server code, as real
client does not report fork-events and vfork-events as supported.

Differential Revision: https://reviews.llvm.org/D100208

show more ...

Reland "[lldb] [Process] Watch for fork/vfork notifications" for Linux

Big thanks to Pavel Labath for figuring out my mistake.

Differential Revision: https://reviews.llvm.org/D98822

Revert "[lldb] [Process] Watch for fork/vfork notifications" and associated followups

This commit has caused the following tests to be flaky:
TestThreadSpecificBpPlusCondition.py
TestExitDuringExpre

Revert "[lldb] [Process] Watch for fork/vfork notifications" and associated followups

This commit has caused the following tests to be flaky:
TestThreadSpecificBpPlusCondition.py
TestExitDuringExpression.py

The exact cause is not known yet, but since both tests deal with
threads, my guess is it has something to do with the tracking of
creation of new threads (which the commit touches upon).

This reverts the following commits:
d01bff8cbdc98fb8751f7bf10af19b47ae5c445d,
ba62ebc48e8c424ce3a78ba01acda679d536dd47,
e761b6b4c58d4f7ae1073d925d7cb321d68ee93a,
a345419ee03095c8cdfbe1c2728467c4da8fa0a4.

show more ...

[lldb] [Process] Watch for fork/vfork notifications

Watch for fork(2)/vfork(2) (also fork/vfork-style clone(2) on Linux)
notifications and explicitly detach the forked child process, and add
initial

[lldb] [Process] Watch for fork/vfork notifications

Watch for fork(2)/vfork(2) (also fork/vfork-style clone(2) on Linux)
notifications and explicitly detach the forked child process, and add
initial tests for these cases. The code covers FreeBSD, Linux
and NetBSD process plugins. There is no new user-visible functionality
provided -- this change lays foundations over subsequent work on fork
support.

Differential Revision: https://reviews.llvm.org/D98822

show more ...

[trace][intel-pt] Implement trace start and trace stop

This implements the interactive trace start and stop methods.

This diff ended up being much larger than I anticipated because, by doing it, I

[trace][intel-pt] Implement trace start and trace stop

This implements the interactive trace start and stop methods.

This diff ended up being much larger than I anticipated because, by doing it, I found that I had implemented in the beginning many things in a non optimal way. In any case, the code is much better now.

There's a lot of boilerplate code due to the gdb-remote protocol, but the main changes are:

- New tracing packets: jLLDBTraceStop, jLLDBTraceStart, jLLDBTraceGetBinaryData. The gdb-remote packet definitions are quite comprehensive.
- Implementation of the "process trace start|stop" and "thread trace start|stop" commands.
- Implementaiton of an API in Trace.h to interact with live traces.
- Created an IntelPTDecoder for live threads, that use the debugger's stop id as checkpoint for its internal cache.
- Added a functionality to stop the process in case "process tracing" is enabled and a new thread can't traced.
- Added tests

I have some ideas to unify the code paths for post mortem and live threads, but I'll do that in another diff.

Differential Revision: https://reviews.llvm.org/D91679

show more ...

[lldb] [Process/FreeBSDRemote] Introduce mips64 support

Introduce mips64 support to match the legacy FreeBSD plugin. Similarly
to the legacy plugin, the code does not support FPU registers at the
mo

[lldb] [Process/FreeBSDRemote] Introduce mips64 support

Introduce mips64 support to match the legacy FreeBSD plugin. Similarly
to the legacy plugin, the code does not support FPU registers at the
moment. The support for them will be submitted separately as it
requires changes to the register context shared by both plugins.

This also includes software single-stepping support that is moved from
the Linux plugin into a common Utility class. The FreeBSD code also
starts explicitly ignoring EINVAL from PT_CLEARSTEP since this is easier
to implement than checking whether hardware single-stepping were used.

Differential Revision: https://reviews.llvm.org/D95802

show more ...

[intel-pt][trace] Implement a "get supported trace type" packet

Depends on D89283.

The goal of this packet (jTraceGetSupportedType) is to be able to query the gdb-server for the tracing technology

[intel-pt][trace] Implement a "get supported trace type" packet

Depends on D89283.

The goal of this packet (jTraceGetSupportedType) is to be able to query the gdb-server for the tracing technology that can work for the current debuggeer, which can make the user experience simpler but allowing the user to simply type

thread trace start

to start tracing the current thread without even telling the debugger to use "intel-pt", for example. Similarly, `thread trace start [args...]` would accept args beloging to the working trace type.

Also, if the user typed

help thread trace start

We could directly show the help information of the trace type that is supported for the target, or mention instead that no tracing is supported, if that's the case.

I added some simple tests, besides, when I ran this on my machine with intel-pt support, I got

$ process plugin packet send "jTraceSupportedType"
packet: jTraceSupportedType
response: {"description":"Intel Processor Trace","pluginName":"intel-pt"}

On a machine without intel-pt support, I got

$ process plugin packet send "jTraceSupportedType"
packet: jTraceSupportedType
response: E00;

Reviewed By: clayborg, labath

Differential Revision: https://reviews.llvm.org/D90490

show more ...

[lldb-server][linux] Add ability to allocate memory

This patch adds support for the _M and _m gdb-remote packets, which
(de)allocate memory in the inferior. This works by "injecting" a
m(un)map sysc

[lldb-server][linux] Add ability to allocate memory

This patch adds support for the _M and _m gdb-remote packets, which
(de)allocate memory in the inferior. This works by "injecting" a
m(un)map syscall into the inferior. This consists of:
- finding an executable page of memory
- writing the syscall opcode to it
- setting up registers according to the os syscall convention
- single stepping over the syscall

The advantage of this approach over calling the mmap function is that
this works even in case the mmap function is buggy or unavailable. The
disadvantage is it is more platform-dependent, which is why this patch
only works on X86 (_32 and _64) right now. Adding support for other
linux architectures should be easy and consist of defining the
appropriate syscall constants. Adding support for other OSes depends on
the its ability to do a similar trick.

Differential Revision: https://reviews.llvm.org/D89124

show more ...

Implement GetSharedLibraryInfoAddress

Summary:
This is the third patch to improve module loading in a series that started here (where I explain the motivation and solution): D62499

Add functions to

Implement GetSharedLibraryInfoAddress

Summary:
This is the third patch to improve module loading in a series that started here (where I explain the motivation and solution): D62499

Add functions to read the r_debug location to know where the linked list of loaded libraries are so I can generate the `xfer:libraries-svr4` packet.
I'm also using this function to implement `GetSharedLibraryInfoAddress` that was "not implemented" for linux.
Most of this code was inspired by the current ds2 implementation here: https://github.com/facebook/ds2/blob/master/Sources/Target/POSIX/ELFProcess.cpp.

Reviewers: clayborg, xiaobai, labath

Reviewed By: clayborg, labath

Subscribers: emaste, krytarowski, mgorny, lldb-commits

Tags: #lldb

Differential Revision: https://reviews.llvm.org/D62501

llvm-svn: 363458

show more ...

Add support to read aux vector values

Summary:
This is the second patch to improve module loading in a series that started here (where I explain the motivation and solution): https://reviews.llvm.or

Add support to read aux vector values

Summary:
This is the second patch to improve module loading in a series that started here (where I explain the motivation and solution): https://reviews.llvm.org/D62499

I need to read the aux vector to know where the r_debug map with the loaded libraries are.
The AuxVector class was made generic so it could be reused between the POSIX-DYLD plugin and NativeProcess*. The class itself ended up in the ProcessUtility plugin.

Reviewers: clayborg, xiaobai, labath, JDevlieghere

Reviewed By: clayborg, labath, JDevlieghere

Subscribers: emaste, JDevlieghere, mgorny, lldb-commits

Tags: #lldb

Differential Revision: https://reviews.llvm.org/D62500

llvm-svn: 363098

show more ...

[NFC] Remove ASCII lines from comments

A lot of comments in LLDB are surrounded by an ASCII line to delimit the
begging and end of the comment.

Its use is not really consistent across the code base

[NFC] Remove ASCII lines from comments

A lot of comments in LLDB are surrounded by an ASCII line to delimit the
begging and end of the comment.

Its use is not really consistent across the code base, sometimes the
lines are longer, sometimes they are shorter and sometimes they are
omitted. Furthermore, it looks kind of weird with the 80 column limit,
where the comment actually extends past the line, but not by much.
Furthermore, when /// is used for Doxygen comments, it looks
particularly odd. And when // is used, it incorrectly gives the
impression that it's actually a Doxygen comment.

I assume these lines were added to improve distinguishing between
comments and code. However, given that todays editors and IDEs do a
great job at highlighting comments, I think it's worth to drop this for
the sake of consistency. The alternative is fixing all the
inconsistencies, which would create a lot more churn.

Differential revision: https://reviews.llvm.org/D60508

llvm-svn: 358135

show more ...

Bring Doxygen comment syntax in sync with LLVM coding style.
This changes '@' prefix to '\'.

llvm-svn: 355841

Update the file headers across all of the LLVM projects in the monorepo
to reflect the new license.

We understand that people may be surprised that we're moving the header
entirely to discuss the ne

Update the file headers across all of the LLVM projects in the monorepo
to reflect the new license.

We understand that people may be surprised that we're moving the header
entirely to discuss the new license. We checked this carefully with the
Foundation's lawyer and we believe this is the correct approach.

Essentially, all code in the project is now made available by the LLVM
project under our new license, so you will see that the license headers
include that license only. Some of our contributors have contributed
code under our old license, and accordingly, we have retained a copy of
our old license notice in the top-level files in each project and
repository.

llvm-svn: 351636

show more ...

Pull FixupBreakpointPCAsNeeded into base class

Summary:
This function existed (with identical code) in both NativeProcessLinux
and NativeProcessNetBSD, and it is likely that it would be useful to an

Pull FixupBreakpointPCAsNeeded into base class

Summary:
This function existed (with identical code) in both NativeProcessLinux
and NativeProcessNetBSD, and it is likely that it would be useful to any
future implementation of NativeProcessProtocol.

Therefore I move it to the base class.

Reviewers: krytarowski

Subscribers: lldb-commits

Differential Revision: https://reviews.llvm.org/D52719

llvm-svn: 343683

show more ...

Pull GetSoftwareBreakpointPCOffset into base class

Summary:
This function encodes the knowledge of whether the PC points to the
breakpoint instruction of the one following it after the breakpoint is

Pull GetSoftwareBreakpointPCOffset into base class

Summary:
This function encodes the knowledge of whether the PC points to the
breakpoint instruction of the one following it after the breakpoint is
"hit". This behavior mainly(*) depends on the architecture and not on the
OS, so it makes sense for it to be implemented in the base class, where
it can be shared between different implementations (Linux and NetBSD
atm).

(*) It is possible for an OS to expose a different API, perhaps by doing
some fixups in the kernel. In this case, the implementation can override
this function to implement custom behavior.

Reviewers: krytarowski, zturner

Subscribers: lldb-commits

Differential Revision: https://reviews.llvm.org/D52532

llvm-svn: 343409

show more ...

NativeProcessProtocol: Sink ReadMemoryWithoutTrap into base class

The two existing implementations have the function implemented
identically, and there's no reason to believe that this would be
diff

NativeProcessProtocol: Sink ReadMemoryWithoutTrap into base class

The two existing implementations have the function implemented
identically, and there's no reason to believe that this would be
different for other implementations.

llvm-svn: 342167

show more ...