diff mbox

Eliminate -var-create error for optzd ptr to struct

Message ID 1459805313-6418-1-git-send-email-donb@codesourcery.com
State New
Headers show

Commit Message

Don Breazeal April 4, 2016, 9:28 p.m. UTC
Hi Yao,

On 4/4/2016 10:16 AM, Don Breazeal wrote:
> On 4/4/2016 3:41 AM, Yao Qi wrote:
>> Don Breazeal <donb@codesourcery.com> writes:
>>
>>> Note that we if value_optimized_out throws an error we just assume
>>> the value is not optimized out.  We let value_rtti_indirect_type
>>> handle any errors, and don't try to duplicate its error handling.
>>
>> I am wondering why does value_optimized_out have to throw an error?
>> Can't we catch the error in value_optimized_out thrown by
>> value_fetch_lazy?
>>
>> I am not very sure on this idea, but I searched the archive, and didn't
>> find anything say we can't do that.
>>
> I looked briefly at all the call sites for value_optimized_out.  It
> looks like if value_optimized_out were to just return 'false' when it
> got a memory error, the result in most cases would be that a subsequent
> memory read would throw an error.  It might be that this could prevent a
> scenario similar to the -var-create error elsewhere in GDB, but there
> wasn't anything obvious in my quick scan.
> 
> I'll change the patch accordingly and run the testsuite.

Also note that in my scan of value_optimized_out call sites, I didn't
notice anywhere that it was explicitly wrapped in a TRY/CATCH block.

I made the changes described above, ran the testsuite on x86_64 Linux (no
regressions), and updated the patch description and ChangeLog.  The updated
patch follows below.

Thanks
--Don

----
This patch eliminates an error thrown when accessing the value of a
pointer to a structure where the pointer has been optimized out and
'set print object' is 'on'.  The error shows up as the rather ugly
value of the pointer variable in Eclipse.

If 'set print object' is 'on', GDB tries to determine the actual
(derived) type of the object rather than the declared type, which
requires dereferencing the pointer, which in this cases throws an
error because the pointer has been optimized out.

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.

To implement the fix, value_optimized_out was modified so that it
no longer throws an error when it fails to fetch the specified
value.  Instead, it just returns 'false'.  If we can't definitively
say that the value is optimized out, then we assume it is not.

Note that this affects other parts of GDB that call
value_optimized_out; however, visual inspection of the code shows
that in all of those cases an error occurring in value_optimized_out
will likely recur in a subsequent attempt to access memory, and the
error will be thrown there.  Meanwhile this change will prevent
other scenarios similar to the one that's fixed 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.

Tested on bare-metal powerpc board with Linux x86 host and Linux
native x86_64.

gdb/ChangeLog:
2016-04-04  Don Breazeal  <donb@codesourcery.com>

	* value.c (value_actual_type): Don't try to get rtti type
	of the value if it has been optimized out.
	(value_optimized_out): Return zero if a memory access
	error occurs.

---
 gdb/value.c | 16 ++++++++++++++--
 1 file changed, 14 insertions(+), 2 deletions(-)

Comments

Yao Qi April 5, 2016, 12:52 p.m. UTC | #1
Don Breazeal <donb@codesourcery.com> writes:

Hi Don,

> @@ -1433,7 +1434,18 @@ value_optimized_out (struct value *value)
>    /* We can only know if a value is optimized out once we have tried to
>       fetch it.  */
>    if (VEC_empty (range_s, value->optimized_out) && value->lazy)
> -    value_fetch_lazy (value);
> +    {
> +      TRY
> +	{
> +	  value_fetch_lazy (value);
> +	}
> +      CATCH (ex, RETURN_MASK_ERROR)
> +	{
> +	  /* If we get an error, assume the value is not optimized out.  */
> +	  return 0;

Why don't we fall back to checking value->optimized_out below?  Some
bits/pieces of value are optimized out, but reading the rest of
bits/piece may trigger the memory error.  In this case, the value is
optimized out too.  We can do this...

         TRY
         {
           value_fetch_lazy (value);
         }
         CATCH (ex, RETURN_MASK_ERROR)
         {
           /* Fall back to checking value->optimized_out.  */
         }
         END_CATCH

What do you think?

> +	}
> +      END_CATCH
> +    }
>  
>    return !VEC_empty (range_s, value->optimized_out);

Note that, after this patch, value_optimized_out will no longer throw
exceptions, some TRY/CATCH in value_optimized_out's callers can be
removed, such as gdbscm_value_optimized_out_p and
valpy_get_is_optimized_out.  This can be done in a follow-up patch.
diff mbox

Patch

diff --git a/gdb/value.c b/gdb/value.c
index 8268b08..90ae193 100644
--- a/gdb/value.c
+++ b/gdb/value.c
@@ -1205,7 +1205,8 @@  value_actual_type (struct value *value, int resolve_simple_types,
       if ((TYPE_CODE (result) == TYPE_CODE_PTR
 	   || TYPE_CODE (result) == TYPE_CODE_REF)
 	  && TYPE_CODE (check_typedef (TYPE_TARGET_TYPE (result)))
-	     == TYPE_CODE_STRUCT)
+	     == TYPE_CODE_STRUCT
+	  && !value_optimized_out (value))
         {
           struct type *real_type;
 
@@ -1433,7 +1434,18 @@  value_optimized_out (struct value *value)
   /* We can only know if a value is optimized out once we have tried to
      fetch it.  */
   if (VEC_empty (range_s, value->optimized_out) && value->lazy)
-    value_fetch_lazy (value);
+    {
+      TRY
+	{
+	  value_fetch_lazy (value);
+	}
+      CATCH (ex, RETURN_MASK_ERROR)
+	{
+	  /* If we get an error, assume the value is not optimized out.  */
+	  return 0;
+	}
+      END_CATCH
+    }
 
   return !VEC_empty (range_s, value->optimized_out);
 }