Re: [PATCH] Consistent display of "<optimized out>"

["Andrew Burgess" <aburgess@broadcom.com>]

On 16/08/2013 7:41 PM, Pedro Alves wrote:
> On 08/12/2013 09:01 PM, Mark Kettenis wrote:
>>> Date: Mon, 12 Aug 2013 14:55:04 +0100
>>> From: Pedro Alves <palves@redhat.com>
>>>
>>> On 08/12/2013 02:31 PM, Andrew Burgess wrote:
>>>> On 06/08/2013 7:39 PM, Pedro Alves wrote:
>>>>> On 08/06/2013 04:41 PM, Mark Kettenis wrote:
>>>>>>> Date: Tue, 6 Aug 2013 14:49:03 +0100
>>>>>>> From: "Andrew Burgess" <aburgess@broadcom.com>
>>>>>
>>>>>>> 3. My understanding was that values lost due to the ABI of a call site
>>>>>>> were recorded as optimized out.  For evidence I would present
>>>>>>> dwarf2_frame_prev_register, and how DWARF2_FRAME_REG_UNDEFINED is handled.
>>>>>>>
>>>>>>> For these reasons I believe my patch should still be considered, what do
>>>>>>> you think?
>>>>>>
>>>>>> I think that registers are either available or unavailble.  A register
>>>>>> being unavailble implies that a variable that is supposed to live in
>>>>>> such a register may have been optimized out.  Whether GDB's pseudo
>>>>>> variables that respresent registers are considered unavailable or
>>>>>> optimized out in that case is arguable.
>>>>>
>>>>> I think improving consistency as in Andrew's patch is good.
>>>>
>>>> Given almost a week has passed with no further feedback I plan to
>>>> commit this patch tomorrow unless there's any further discussion to be had.
>>>
>>> TBC, note my opinion doesn't get to overrule Mark's.  Consensus
>>> works much better, and Mark does have deep knowledge of all
>>> ABI/pseudo registers/etc. gdb things.
>>> That said, Mark, if you still disagree, please counter argue,
>>> otherwise, we'll just have to assume you do agree with the
>>> rationales and clarifications.
>>
>> Can't say I agree.  It simply doesn't make sense for registers to be
>> "optimized out".  I guess there are two reasons why GDB can't display
>> the contents of a register in a frame:
>>
>> 1. The register contents aren't made available by the debugging
>>    interface, i.e. ptrace(2) or the remote stub doesn't tell us.
>>
>> 2. The register wasn't saved before calling another function.
>>
>> I guess after Andrew's chnages 1) would be shown as <unavailable> and
>> 2) would become <optimized out>.  But in the latter case something
>> like <not saved> would make more sense.
>>
>> That said, Pedro, you're pretty much the expert for this area of GDB.
>> So If you think Andrew should go ahead with this, feel free to ignore
>> me.
> 
> This is a tough call.  I do agree that "optimized out" for registers
> is a bit confusing.  However, we already do print "<optimized out>" in
> other places, such as when printing expressions, and consistency
> is good.  If we did add a distinction, I agree with Andrew that it should
> be done in a more systematic way.  However, I'm not really sure we need
> much machinery.  Wouldn't something like:
> 
> void
> val_print_optimized_out (const struct value *val, struct ui_file *stream)
> {
>   if (value_lval_const (val) == lval_register)
>     fprintf_filtered (stream, _("<not saved>"));
>   else
>     fprintf_filtered (stream, _("<optimized out>"));
> }
> 
> work?  What could be the register value cases that would print
> "not saved" that we'd still want to print "optimized out" ?

The only case I can immediately think of where this would cause a
problem would be for computed locations, (lval_computed).  The easy
answer would be (in that case) the blame the compiler - why say the
location is in a register if that register is volatile - but sadly I see
this way too often.

However, exchanging what I see as the current larger inconsistency, for
this much smaller one seems like a good deal to me, especially if it
gets this patch unblocked...

Thanks,
Andrew