This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [PATCH] optimized out registers in mi
- From: "Andrew Burgess" <aburgess at broadcom dot com>
- To: "Pedro Alves" <palves at redhat dot com>
- Cc: "gdb-patches at sourceware dot org" <gdb-patches at sourceware dot org>
- Date: Fri, 5 Jul 2013 17:37:58 +0100
- Subject: Re: [PATCH] optimized out registers in mi
- References: <51D6C9D8 dot 4000502 at broadcom dot com> <51D6D22E dot 2030807 at redhat dot com>
On 05/07/2013 3:03 PM, Pedro Alves wrote:
> On 07/05/2013 02:27 PM, Andrew Burgess wrote:
>
>> [1] I applied a patch yesterday that changed value_optimized_out,
>> before I applied yesterdays patch the behaviour of -data-list-registers
>> was a bit random, if the register value was lazy then you would get
>> the "<optimized out>" result, if the value was not lazy then you got
>> the error. Of the two behaviours I think returning the
>> "<optimized out>" string is by far the most helpful so that's
>> the behaviour we now get in all cases.
>
> Agreed.
>
> It'd be nice to handle partially optimized out registers
> too, though I'm not sure gcc does something like that
> currently. And that can be always handled later. This
> is already a good step.
>
>> gdb/ChangeLog
>
>> - if (format == 'N')
>> + /* Displaying optimized out values using anything other than the default
>> + format will result in the value 0 being shown. */
>
> Please make that s/will/would/. It's confusing as is; it made
> me think that printing 0 was what the patch was meaning to do.
>
> But, this looks hacky to me. Do we print 0 with the CLI as well?
> If not, what's handling it that's missing in MI? Isn't this being
> handled gracefully somewhere within val_print itself (I'd
> think in val_print_scalar_formatted)?
The answer to this is a few lines down in the function, it is really the
'r' formatting case that I'm trying to avoid, as this is handled as a
special within the output_register function.
So, I could probably write:
if ((value_optimized_out (val) && format == 'r') || format == 'N')
NOTE: The format == 'N' stuff is not mine, and was there before.
I didn't write this as I figured the result would be the same whatever
format you send into the print code if the value is optimized_out.
Now, the next question that comes to me is, why do we handle 'r' as a
special case inside output_register.... I can't answer that one, maybe
we could / should move it into the generic print code, then you'd be
correct and the whole optimized_out check would not be needed. Would
your prefer me to try to move the format-'r' code, or is my original
patch ok?
Cheers,
Andrew