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

[Mark Kettenis <mark dot kettenis at xs4all dot nl>]

> Date: Tue, 6 Aug 2013 14:49:03 +0100
> From: "Andrew Burgess" <aburgess@broadcom.com>
> 
> On 06/08/2013 2:18 PM, Mark Kettenis wrote:
> >> Date: Tue, 6 Aug 2013 14:08:46 +0100
> >> From: "Andrew Burgess" <aburgess@broadcom.com>
> >>
> >> In some cases we report optimized out registers as "*value not available*"
> >> rather than "<optimized out>", the patch below makes this more consistent
> >> in the case I've spotted.
> >>
> >> Here's an example:
> >>
> >> (gdb) up
> >> #1  0x0000000000400800 in first_frame () at dw2-reg-undefined.c:27
> >> 27      in dw2-reg-undefined.c
> >> (gdb) info registers rax
> >> rax            *value not available*
> >> (gdb) p/x $rax
> >> $1 = <optimized out>
> >>
> >> After the patch the behaviour is now:
> >>
> >> (gdb) up
> >> #1  0x0000000000400800 in first_frame () at dw2-reg-undefined.c:27
> >> 27      in dw2-reg-undefined.c
> >> (gdb) info registers rax
> >> rax            <optimized out>
> >> (gdb) p/x $rax
> >> $1 = <optimized out>
> >>
> >> The behaviour for values that are unavailable is currently unchanged,
> >> though I have a follow up patch for this too.
> >>
> >> OK to apply?
> > 
> > I'd say no.  There is a difference between "unavailable" and
> > "optimized out".  Registers will be unavailable even if you compile
> > without any optimization, because the ABI specifies that their
> > contents are not saved across function calls.  So "optimized out"
> > makes very little sense for registers.
> 
> I disagree for 3 reasons.
> 
> 1. This patch is about consistency, having "print <reg>" report one
> thing and "info register <reg>" report another seems like a bad thing to
> me.
> 
> 2. We previously fetched the register by calling
> deprecated_frame_register_read, this eventually gets a value object by
> called frame_unwind_register_value, we then extract the unavailable and
> optimized-out attributes from the value object and for no good reason I
> can see create a new value object and mark it as unavailable.  My patch
> side-steps this middle ground of calling
> deprecated_frame_register_read, and instead works with the value we get
> back by reading the register, this is already marked optimized out.  My
> interpretation of your concern would be that you don't think it /should/
> be marked as optimized out, I believe however, that this is not really
> an issue for this patch, if this changes later then we'd revert back to
> printing unavailable rather than optimized out, my patch doesn't prevent
> that, it just prints the real state of the value object.
> 
> 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.