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

[Konstantin Belousov]

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.

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.

When waitpid(2) reports the process exit, you should have only one LWP left
in your registry of the process' threads. Clean it.

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?

Some syscalls return two values, e.q. pipe(2), which needs to return fds
for in and out pipes. Less visible, fork(2) returns zero for child process,
but also the parent pid as an additional value, not exposed by C wrapper.

On 32bit arches, lseek(2) needs to return 64bit result, which requires
two registers. Same for read(2)/write(2).


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Konstantin Belousov]

Post by Konstantin Belousov

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.

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.

When waitpid(2) reports the process exit, you should have only one LWP left
in your registry of the process' threads. Clean it.

Slight correction: process can exit with more than one thread still running.
You should clean all threads belonging to the exited process.

Post by Konstantin Belousov

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?

Some syscalls return two values, e.q. pipe(2), which needs to return fds
for in and out pipes. Less visible, fork(2) returns zero for child process,
but also the parent pid as an additional value, not exposed by C wrapper.
On 32bit arches, lseek(2) needs to return 64bit result, which requires
two registers. Same for read(2)/write(2).

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Konstantin Belousov]

Post by Konstantin Belousov

Hello everyone!
I am porting my so far linux-only FOSS project 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.

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.

When waitpid(2) reports the process exit, you should have only one LWP left
in your registry of the process' threads. Clean it.

By registry are you referring to a registry that exists in the system and accessed somehow, like with sysctl, or are you telling me that I should indeed keep a registry about which threads belong to which processes in the code? :D.
Doing so won't significantly complicate things, but extra state is extra state, so just wondered if it could be avoided somehow!

Since you are saying that you need to clear the state, you alread have the
state recorded somewhere.

Post by Konstantin Belousov

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?

Some syscalls return two values, e.q. pipe(2), which needs to return fds
for in and out pipes. Less visible, fork(2) returns zero for child process,
but also the parent pid as an additional value, not exposed by C wrapper.
On 32bit arches, lseek(2) needs to return 64bit result, which requires
two registers. Same for read(2)/write(2).

I see, so for syscalls with a single return value, is it safe to assume that it's always going to be at sr_retval[0]?

For lseek/read/write etc it depends on the architecture.


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de