Detecting the death of the last LWP of a tracee process.

From: fvalasiad <fvalasiad_at_proton.me>
Date: Tue, 27 Aug 2024 21:38:30 UTC
Hello everyone!

I am porting my so far linux-only FOSS project [build recorder](https://github.com/fvalasiad/build-recorder) to FreeBSD "unofficially", as if, in my own personal fork and not the parent organization's upstream repository.
All for fun in my personal time, uncertain if and when it's gonna be merged upstream.

As you can probably guess it utilizes ptrace(2), and I am facing some issues with it.

manpage states this about the PTRACE_LWP flag:

> Note that new processes do not report an event for
> the creation of their	initial	thread,  and  exiting
> processes do not report an event for the termination
> of the last thread.

This is kind of a bummer for my tool's needs. In case anyone is unfamiliar with threads in linux, they are essentially processes and there is no distinction between them. Trying to minimize the conditional compilation of my project to make maintaining it easier, I took
advantage of the fact that LWPs have unique system-wide IDs, almost completely
ignoring the distinction amongst processes and LWPs in my tool....

This though ruins everything, as I cannot properly clean the process' last LWP state
without knowing its ID upon exit. Manpage states that you should do that through normal
process signals, but once the process sends the WEXITED signal, the process and all info
with it(namely, its last LWP's ID) is gone. Curious if there is a workaround besides adding
extra state.

Additionally, if anyone could help explain what PT_GET_SC_RET's double return value is all about. How can a traditional system call like open(2) have two return values?

Thanks for your attention!
Fotis