[lldb][FreeBSD] Fix a typo in NativeProcessFreeBSD::MonitorSIGTRAP() (#109643)

Apparently a typo is causing compile error, added by https://github.com/llvm/llvm-project/pull/108504.

[lldb] Add pc check for thread-step-by-bp algorithms (#108504)

lldb-server built with NativeProcessLinux.cpp and
NativeProcessFreeBSD.cpp can use breakpoints to implement instruction
stepping on c

[lldb] Add pc check for thread-step-by-bp algorithms (#108504)

lldb-server built with NativeProcessLinux.cpp and
NativeProcessFreeBSD.cpp can use breakpoints to implement instruction
stepping on cores where there is no native instruction-step primitive.
Currently these set a breakpoint, continue, and if we hit the breakpoint
with the original thread, set the stop reason to be "trace".

I am wrapping up a change to lldb's breakpoint algorithm where I change
its current behavior of

"if a thread stops at a breakpoint site, we set
the thread's stop reason to breakpoint-hit, even if the breakpoint
hasn't been executed" +
"when resuming any thread at a breakpoint site, instruction-step past
the breakpoint before resuming"

to a behavior of

"when a thread executes a breakpoint, set the stop reason to
breakpoint-hit" +
"when a thread has hit a breakpoint, when the thread resumes, we
silently step past the breakpoint and then resume the thread".

For these lldb-server targets doing breakpoint stepping, this means that
if we are sitting on a breakpoint that has not yet executed, and
instruction-step the thread, we will execute the breakpoint instruction
at $pc (instead of $next-pc where it meant to go), and stop again -- at
the same pc value. Then we will rewrite the stop reason to 'trace'. The
higher level logic will see that we haven't hit the breakpoint
instruction again, so it will try to instruction step again, hitting the
breakpoint again forever.

To fix this, I'm checking that the thread matches the one we are
instruction-stepping-by-breakpoint AND that we've stopped at the
breakpoint address we are stepping to. Only in that case will the stop
reason be rewritten to "trace" hiding the implementation detail that the
step was done by breakpoints.

show more ...

[lldb] Update NativeProcess*BSD to new Status API

[lldb] Turn lldb_private::Status into a value type. (#106163)

This patch removes all of the Set.* methods from Status.

This cleanup is part of a series of patches that make it harder use the
ant

[lldb] Turn lldb_private::Status into a value type. (#106163)

This patch removes all of the Set.* methods from Status.

This cleanup is part of a series of patches that make it harder use the
anti-pattern of keeping a long-lives Status object around and updating
it while dropping any errors it contains on the floor.

This patch is largely NFC, the more interesting next steps this enables
is to:
1. remove Status.Clear()
2. assert that Status::operator=() never overwrites an error
3. remove Status::operator=()

Note that step (2) will bring 90% of the benefits for users, and step
(3) will dramatically clean up the error handling code in various
places. In the end my goal is to convert all APIs that are of the form

` ResultTy DoFoo(Status& error)
`
to

` llvm::Expected<ResultTy> DoFoo()
`
How to read this patch?

The interesting changes are in Status.h and Status.cpp, all other
changes are mostly

` perl -pi -e 's/\.SetErrorString/ = Status::FromErrorString/g' $(git
grep -l SetErrorString lldb/source)
`
plus the occasional manual cleanup.

show more ...

[lldb][FreeBSD] Fix crash when execve fails with asserts enabled

535da10842c7309e9eeaf9828cf6bb034fecaf16 introduced a check, when execve fails,
to see if we are allowed to trace programs at all.

U

[lldb][FreeBSD] Fix crash when execve fails with asserts enabled

535da10842c7309e9eeaf9828cf6bb034fecaf16 introduced a check, when execve fails,
to see if we are allowed to trace programs at all.

Unfortunately because we like to call Status vars "error" and "status"
in various combinations, one got misnamed. This lead to lldb-server trying
to make an error value out of a success value when you did the following:

```
$ ./bin/lldb-server gdbserver 127.0.0.1:1234 -- is_not_a_file
Assertion failed: (Err && "Cannot create Expected<T> from Error success value."), function Expected...
```

This happened because the execve fails, but the check whether we can
trace says yes we can trace, but then we use the Status from the check
to create the return value. That Status is in fact a success value not
the failed Status we got from the execve attempt.

With the name corrected you now get:
```
$ ./bin/lldb-server gdbserver 127.0.0.1:1234 -- is_not_a_file
error: failed to launch 'is_not_a_file': execve failed: No such file or directory
```

Which is what we expect to see. This also fixes the test `TestGDBRemoteLaunch.py`
when asserts are enabled.

show more ...

[lldb] checks if lldb can trace/attach/set a breakpoint a process or load a file to debug on FreeBSD.

before having the generic EINVAL message, we check if the
`security.bsd.unprivileged_proc_debug

[lldb] checks if lldb can trace/attach/set a breakpoint a process or load a file to debug on FreeBSD.

before having the generic EINVAL message, we check if the
`security.bsd.unprivileged_proc_debug` allows process debugging.

close #79634

show more ...

[lldb][NFC] Use UNUSED_IF_ASSERT_DISABLED instead of (void) cast

Uses of (void) remain where they are for purposes other than an
assert variable.

[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 ...

Move from llvm::makeArrayRef to ArrayRef deduction guides - last part

This is a follow-up to https://reviews.llvm.org/D140896, split into
several parts as it touches a lot of files.

Differential Re

Move from llvm::makeArrayRef to ArrayRef deduction guides - last part

This is a follow-up to https://reviews.llvm.org/D140896, split into
several parts as it touches a lot of files.

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

show more ...

[lldb] [Process/FreeBSD] Do not send SIGSTOP to stopped process

Do not send SIGSTOP when requested to halt a process that's already
stopped. This results in the signal being queued for delivery onc

[lldb] [Process/FreeBSD] Do not send SIGSTOP to stopped process

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

show more ...

[lldb] Convert POSIXLog to use the new API

[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] [Process/FreeBSD] Set current thread ID on events

Set the current thread ID to the thread where an event happened.
As a result, e.g. when a signal is delivered to a thread other than
the firs

[lldb] [Process/FreeBSD] Set current thread ID on events

Set the current thread ID to the thread where an event happened.
As a result, e.g. when a signal is delivered to a thread other than
the first one, the respective T packet refers to the signaled thread
rather than the first thread (with no stop reason). While this doesn't
strictly make a difference to the LLDB client, it is the expected
behavior.

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

show more ...

[lldb] [FreeBSD] Fix building on systems without PT_COREDUMP

PT_COREDUMP is a relatively recent addition. Use an #ifdef to skip it
if the underlying system does not support it.

Differential Revisi

[lldb] [FreeBSD] Fix building on systems without PT_COREDUMP

PT_COREDUMP is a relatively recent addition. Use an #ifdef to skip it
if the underlying system does not support it.

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

show more ...

[lldb] [Process/FreeBSD] Support SaveCore() using PT_COREDUMP

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

[lldb] [gdb-remote] Report QPassSignals and qXfer via extensions API

Remove hardcoded platform list for QPassSignals, qXfer:auxv:read
and qXfer:libraries-svr4:read and instead query the process plug

[lldb] [gdb-remote] Report QPassSignals and qXfer via extensions API

Remove hardcoded platform list for QPassSignals, qXfer:auxv:read
and qXfer:libraries-svr4:read and instead query the process plugin
via the GetSupportedExtensions() API.

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

show more ...

[lldb] [Process/FreeBSD] Report fork/vfork events to LLGS

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

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

The original commit was reverted because of the problems it introduced
on Linux. However, FreeBSD should not be affected, so

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

The original commit was reverted because of the problems it introduced
on Linux. However, FreeBSD should not be affected, so restore that part
and we will address Linux separately.

While at it, remove the dbreg hack as the underlying issue has been
fixed in the FreeBSD kernel and the problem is unlikely to happen
in real life use anyway.

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

show more ...

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] Replace NativeProcess delegate list with a single delegate

In all this time, we've never used more than one delegate. The logic to
support multiple delegates is therefore untested, and become

[lldb] Replace NativeProcess delegate list with a single delegate

In all this time, we've never used more than one delegate. The logic to
support multiple delegates is therefore untested, and becomes
particularly unwieldy once we need to support multiple processes.

Just remove it.

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 ...

[lldb] [Process/FreeBSD] Introduce aarch64 hw break/watchpoint support

Split out the common base of Linux hardware breakpoint/watchpoint
support for AArch64 into a Utility class, and use it to imple

[lldb] [Process/FreeBSD] Introduce aarch64 hw break/watchpoint support

Split out the common base of Linux hardware breakpoint/watchpoint
support for AArch64 into a Utility class, and use it to implement
the matching support on FreeBSD.

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

show more ...

[lldb] [Process/FreeBSD] Ensure that errors are always handled

Ensure that the llvm::Error instances are always considered handled
by replacing LLDB_LOG with LLDB_LOG_ERROR.

Differential Revision:

[lldb] [Process/FreeBSD] Ensure that errors are always handled

Ensure that the llvm::Error instances are always considered handled
by replacing LLDB_LOG with LLDB_LOG_ERROR.

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

show more ...

[lldb] Rename FreeBSDRemote to FreeBSD (NFC)

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