public inbox for gdb-patches@sourceware.org
 help / color / mirror / Atom feed
From: Luis Machado <lgustavo@codesourcery.com>
To: Don Breazeal <donb@codesourcery.com>, <gdb-patches@sourceware.org>
Subject: Re: [PATCH] Eliminate -var-create error for optzd ptr to struct
Date: Wed, 24 Feb 2016 01:14:00 -0000	[thread overview]
Message-ID: <56CD03F5.6080505@codesourcery.com> (raw)
In-Reply-To: <1456273154-28629-1-git-send-email-donb@codesourcery.com>

On 02/23/2016 09:19 PM, Don Breazeal wrote:
> Problem:
> This patch eliminates an error thrown when accessing the value of a
> pointer to a structure where the pointer has been optimized out.
> The error shows up as the rather ugly value of the pointer variable
> in Eclipse.
>
> With this change such an access will return "<optimized out>" like
> other optimized out variables.  We should throw an error when
> dereferencing an optimized-out pointer, but not when just looking
> at its value.
>
> Cause:
> The error only occurs when '-gdb-set print object on' has been set.
> This setting requires GDB to "identify the actual (derived) type of
> the object rather than the declared type".  Part of this process
> is to dereference the pointer in order to get the type of the thing
> that is pointed-to.  Since the pointer has been optimized out, this
> is impossible, and an error is thrown.
>
> Fix:
> The fix is to simply ignore the 'print object on' setting for
> pointers or references to structures when they have been optimized
> out.  This means we just get the declared type instead of the actual
> type, because in this case that's the best that we can do.
>
> Results:
> Attempts to dereference the optimized-out pointer using -var-create
> or -data-evaluate-expression will throw an error, but a dereference
> using -var-evaluate-expression will return an empty value.  To be
> consistent, this last case would also throw an error.  I looked into
> this some, enough to confirm that there isn't an obvious fix.  Given
> that my goal is just to eliminate the unnecessary error, I stopped here.
>
> I'm working on setting things in motion for a patch to Eclipse that
> recognizes optimized-out pointer-to-struct in this scenario and
> prevents any subsequent attempt to dereference it from that end.
>
> Testing:
> I looked at creating a test case for this, but so far haven't been
> able to create anything general enough to include in the test suite.
>
> Tested on bare-metal powerpc board with Linux x86_64 host.
>
> OK?
>
> thanks
> --Don
>
> gdb/ChangeLog:
> 2016-02-23  Don Breazeal  <donb@codesourcery.com>
>
> 	* gdb/value.c (value_actual_type): Ignore the 'print object
> 	  on' setting for pointers and references to structures.
>
> ---
>   gdb/value.c | 5 +++--
>   1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/gdb/value.c b/gdb/value.c
> index 738b2b2..50e4f8a 100644
> --- a/gdb/value.c
> +++ b/gdb/value.c
> @@ -1203,9 +1203,10 @@ value_actual_type (struct value *value, int resolve_simple_types,
>         /* If result's target type is TYPE_CODE_STRUCT, proceed to
>   	 fetch its rtti type.  */
>         if ((TYPE_CODE (result) == TYPE_CODE_PTR
> -	  || TYPE_CODE (result) == TYPE_CODE_REF)
> +	   || TYPE_CODE (result) == TYPE_CODE_REF)

Is this just a formatting change?

>   	  && TYPE_CODE (check_typedef (TYPE_TARGET_TYPE (result)))
> -	     == TYPE_CODE_STRUCT)
> +	     == TYPE_CODE_STRUCT
> +	  && !value_optimized_out (value))
>           {
>             struct type *real_type;
>

Otherwise looks OK to me.

As for the testcase, how about one that creates a few pointer variables 
(to basic types, structures, arrays and other meaningful ones) and tries 
to print their original values with the "print object" enabled. This 
would be in MI mode, of course.

I'd expect the error to be thrown in an unpatched gdb and a <optimized 
out> string for the patched debugger.

  reply	other threads:[~2016-02-24  1:14 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-02-24  0:19 Don Breazeal
2016-02-24  1:14 ` Luis Machado [this message]
2016-02-24 16:31   ` Don Breazeal
2016-02-25 12:22     ` Pedro Alves
2016-03-28 21:33       ` [PATCH v2 0/2] Optzd-out ptr: Error handling improvement Don Breazeal
2016-03-28 21:34         ` [PATCH v2 1/2] Optzd-out ptr: New test for error handling Don Breazeal
2016-03-29 11:58           ` Yao Qi
2016-03-29 17:13             ` Don Breazeal
2016-03-30 14:37               ` Yao Qi
2016-04-06 21:34                 ` Don Breazeal
2016-03-28 21:34         ` [PATCH v2 2/2] Optzd-out ptr: Eliminate -var-create error Don Breazeal
2016-03-29 12:01     ` [PATCH] Eliminate -var-create error for optzd ptr to struct Yao Qi
2016-03-29 17:14       ` Don Breazeal
2016-03-30 14:35         ` Yao Qi
2016-04-01 16:01           ` Don Breazeal
2016-04-04 10:42             ` Yao Qi
2016-04-04 17:16               ` Don Breazeal
2016-04-04 21:28           ` Don Breazeal
2016-04-05 12:53             ` Yao Qi
2016-04-05 18:51               ` Don Breazeal
2016-04-05 19:00                 ` Pedro Alves
2016-04-05 20:39                   ` Don Breazeal
2016-04-06  9:05                     ` Yao Qi
2016-04-06 21:41                       ` Don Breazeal
2016-04-06 22:24                         ` Pedro Alves
2016-04-07 14:12                         ` Yao Qi

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=56CD03F5.6080505@codesourcery.com \
    --to=lgustavo@codesourcery.com \
    --cc=donb@codesourcery.com \
    --cc=gdb-patches@sourceware.org \
    /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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).