This is the mail archive of the
mailing list for the GDB project.
Re: [PATCH] Eliminate -var-create error for optzd ptr to struct
- From: Don Breazeal <donb at codesourcery dot com>
- To: <qiyaoltc at gmail dot com>, <gdb-patches at sourceware dot org>
- Date: Mon, 4 Apr 2016 14:28:33 -0700
- Subject: Re: [PATCH] Eliminate -var-create error for optzd ptr to struct
- Authentication-results: sourceware.org; auth=none
On 4/4/2016 10:16 AM, Don Breazeal wrote:
> On 4/4/2016 3:41 AM, Yao Qi wrote:
>> Don Breazeal <email@example.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
>> 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.
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
2016-04-04 Don Breazeal <firstname.lastname@example.org>
* 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
gdb/value.c | 16 ++++++++++++++--
1 file changed, 14 insertions(+), 2 deletions(-)
diff --git a/gdb/value.c b/gdb/value.c
index 8268b08..90ae193 100644
@@ -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);
+ value_fetch_lazy (value);
+ CATCH (ex, RETURN_MASK_ERROR)
+ /* If we get an error, assume the value is not optimized out. */
+ return 0;
return !VEC_empty (range_s, value->optimized_out);