Re: [RFC/PATCH] New convenience variable $_exitsignal

[Tom Tromey <tromey@redhat.com>]

Pedro> Well, guess you've missed it, because from the beginning I had already
Pedro> introduced that as pedantic:

Thanks.

Pedro> Consider non-stop, and using gcore for snapshotting the program
Pedro> state.  There's no termination/exit at all.  In fact, there's are
Pedro> potentially many threads in the program, and each of them, if
Pedro> stopped, should have its own signal number.  You should be able
Pedro> to get at all of them with $_siginfo.si_signo, but it's just that
Pedro> older kernels don't have that info.  Let's pretend kernels did
Pedro> always write NT_SIGINFO.  Would we be arguing for making
Pedro> $_exitsignal work for cores, given that $si_siginfo.si_signo
Pedro> would work?  It's plausible.  And that's why I'm not against this
Pedro> at all.  I just wanted to make sure that design decision is
Pedro> use-case driven, rather than because on Linux's current
Pedro> implementation such-and-such happens.  IOW, I wanted that to be
Pedro> recorded on the archives, so if even if the core formats change
Pedro> in the future, we can refer back to today's decisions.

Thanks, that is a nice summary for those of us who lost track.  Which
may just be me, but still.  Also, let me say that I continue to find it
delightful how you have all the hard cases at hand, ready to roll out
over my simplistic arguments :-)

>> Another consideration along these lines is that I have a branch in
>> progress for "catch exit" -- it's been waiting for Sergio's work on
>> these convenience variables.  I think here as well $_exitsignal seems
>> like a natural fit, even though the process has not technically exited
>> at the catchpoint.

Pedro> I see, thanks.  Sounds reasonable.

I see now from your explanation that the cases are in fact different.
The "catch exit" case is more clearly a direct mapping.

Tom