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

[Pedro Alves <palves at redhat dot com>]

On 09/17/2013 07:36 PM, Tom Tromey wrote:
>>>>>> "Pedro" == Pedro Alves <palves@redhat.com> writes:
> 
> Pedro> I can't say I really understand how any of that argues against my
> Pedro> original rationale for not setting $_exitsignal on corefiles (because
> Pedro> the inferior has not really exited at the point the core has been
> Pedro> generated), rather than point at implementation choices.
> 
> Pedro> Now, if one were to instead argue that _user interface_ -wise, it'd
> Pedro> make sense to set $_exitsignal, because we also print
> Pedro> "Program terminated with signal", (emphasis on "terminated"), then
> Pedro> I'd agree:
> 
> I may have missed part of the thread, but what is the rationale for
> being so precise here?  It seems a bit pedantic to me -- which is fine
> if there is a purpose to it, but I couldn't think of one in this case.

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

 https://sourceware.org/ml/gdb-patches/2013-06/msg00337.html

Also, if you read downthread, you'll notice that I have agreed to being lax
here, just not the presented rationale for it.  If we're deciding to set the
flag for cores, then IMO, it's important such decisions are conscientiously
based on a user interface decisions, not of the style "I think it'd make
sense, but I'd have to do such and such".

> That is, gdb has a bit of information that is relevant to the user.  It
> is useful to users if we expose it to them in a script-friendly way.  We
> already have $_exitsignal, and differentiating between "the program
> exited with signal X" and "the program is about to exit with signal X"
> doesn't seem particularly handy.

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

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

I see, thanks.  Sounds reasonable.

-- 
Pedro Alves