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

[Pedro Alves <palves@redhat.com>]

On 09/17/2013 01:11 AM, Sergio Durigan Junior wrote:

>> I can't say I really understand how any of that argues against my
>> original rationale for not setting $_exitsignal on corefiles (because
>> the inferior has not really exited at the point the core has been
>> generated), rather than point at implementation choices.
> 
> Interesting.  I thought setting it made sense because it seems to me
> that the inferior has exited when the corefile has been generated.  I am
> clearly missing some knowledge here, then...

Then that's what you need to argue.  ;-) My point of view was that
when inspecting a core dump, you're seeing the state of the
program _before_ it exited.  E.g, if you stop the program (with a
breakpoint, ctrl-c, or even "interrupt -a"/non-stop), do "gcore", and
then debug the resulting core, the program never exited.

>> Now, if one were to instead argue that _user interface_ -wise, it'd
>> make sense to set $_exitsignal, because we also print
>> "Program terminated with signal", (emphasis on "terminated"), then
>> I'd agree:
>>
>>   siggy = bfd_core_file_failing_signal (core_bfd);
>>   if (siggy > 0)
>>     {
>> ...
>>       printf_filtered (_("Program terminated with signal %s, %s.\n"),
>> 		       gdb_signal_to_name (sig), gdb_signal_to_string (sig));
>>     }
> 
> ...or not.  Apparently, you are differentiating between "exited" and
> "terminated", right?  Could you expand a little more on this?

No, not differentiating.  The emphasis was for pointing out that GDB already
claims the program has indeed terminated, so from that perspective, it does
indeed make sense to set $_exitsignal, otherwise, to make things consistent,
_I_, in turn, would need to argue for removing that "Program terminated with
signal" message.  I don't plan to, so I get to agree with setting $_exitsignal.
See, this is all about _user interface_, not random internal implementation
choices, which will naturally change over time, but the user interface design
decision will most probably outlast that for a long while.

> And BTW, I guess my reasoning for setting $_exitsignal here is indeed
> because we already assume that the inferior has been terminated (or
> exited?) indeed.

Thanks,
-- 
Pedro Alves