From: "Andrew Burgess" <aburgess@broadcom.com>
To: "Pedro Alves" <palves@redhat.com>
Cc: "gdb-patches@sourceware.org" <gdb-patches@sourceware.org>
Subject: Re: [PATCH] optimized out registers in mi
Date: Fri, 05 Jul 2013 16:38:00 -0000 [thread overview]
Message-ID: <51D6F666.4030400@broadcom.com> (raw)
In-Reply-To: <51D6D22E.2030807@redhat.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
next prev parent reply other threads:[~2013-07-05 16:38 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-07-05 13:28 Andrew Burgess
2013-07-05 14:03 ` Pedro Alves
2013-07-05 16:38 ` Andrew Burgess [this message]
2013-07-05 18:17 ` Pedro Alves
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=51D6F666.4030400@broadcom.com \
--to=aburgess@broadcom.com \
--cc=gdb-patches@sourceware.org \
--cc=palves@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox