Re: [PATCH v3] Implement $_exitsignal

[Pedro Alves <palves at redhat dot com>]

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

>>> +	  if (gdbarch_gdb_signal_to_target_p (gdbarch))
>>> +	    signo = (LONGEST) gdbarch_gdb_signal_to_target (gdbarch,
>>> +							    ecs->ws.value.sig);
>>> +	  else if (gdb_signal_to_host_p (ecs->ws.value.sig))
>>> +	    {
>>> +	      /* This is a workaround.  If we don't have a way to a
>>> +		 way of converting a signal using the target's
>>> +		 notation (which is the best), then we at least offer
>>> +		 the conversion using the host's notation.  This will
>>> +		 be OK as long as the user is not doing remote
>>> +		 debugging with target != host.  */
>>> +	      signo = (LONGEST) gdb_signal_to_host (ecs->ws.value.sig);
>>> +	    }
>>> +	  else
>>> +	    {
>>> +	      /* This is *ugly*, but if we can't even rely on the host
>>> +		 converstion, then the least we can do is to print
>>> +		 GDB's internal signal number.  */
>>> +	      signo = (LONGEST) ecs->ws.value.sig;
>>> +	    }
>>
>> Urgh.  I'm really not sure this fallbacks are a good idea.
>> The last one in particular looks very nasty.  The old code in corelow.c
>> that falls back to a host conversion is there because it's very
>> old code that existed way before gdb even gained proper support for
>> cross debugging.  I think for new functionality we should pick one of either
>> just not supporting the feature if we can't do a proper
>> gdbarch_gdb_signal_to_target conversion, or always exporting the GDB internal
>> number (*).
> 
> What do you mean by "always exporting the GDB internal number"?  Always
> printing this internal number to the user, without converting it first?

Yes.

>> A mixed solution like that just doesn't look right to me.  The
>> new tests will happen to pass for most targets/hosts, because the values of
>> common signals like SIGABRT and SIGSEGV will happen to coincide with gdb's
>> own numbers.
> 
> OK, makes sense to me.  Then my opinion is that we should somehow not
> support filling $_exitsignal if there is no
> gdbarch_gdb_signal_to_target, i.e., we should clear the convenience
> variable and leave it alone.  I don't like the idea of exposing GDB's
> internal number because there may/will be discrepancies already
> discussed (unless that's not what you meant above).

OK, fine with me.

Thanks,
-- 
Pedro Alves