Re: [PATCH] Eliminate -var-create error for optzd ptr to struct

Re: [PATCH] Eliminate -var-create error for optzd ptr to struct

[Don Breazeal]

Hi Yao,

On 4/5/2016 5:52 AM, Yao Qi wrote:
> Don Breazeal <donb@codesourcery.com> writes:

>> +      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?

Of course, that makes more sense, thanks.

> 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.

I've done a more thorough audit of the call sites for value_optimized_out
than I did previously, and the only places where an enclosing TRY/CATCH can
be removed are the two you name.  There is one other place where it is
called inside a TRY/CATCH, but there are other functions that could throw
errors called there as well.

I will create a follow-up patch.

I changed this patch as you suggest above, as well as changing
RETURN_MASK_ERROR to RETURN_MASK_ALL.  The TRY/CATCH blocks that are
going to be removed use RETURN_MASK_ALL, and I thought that this patch
should maintain the same level of coverage.

Re-tested on native Linux x86_64.

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.  If we can't definitively say that the value is optimized
out, then we assume it is not.

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-05  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): If a memory access error occurs,
	fall back to just checking value->optimized_out.

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

diff --git a/gdb/value.c b/gdb/value.c
index 8268b08..8a210e7 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,17 @@ 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_ALL)
+	{
+	  /* Fall back to checking value->optimized_out.  */
+	}
+      END_CATCH
+    }
 
   return !VEC_empty (range_s, value->optimized_out);
 }
-- 
1.8.1.1

Re: [PATCH] Eliminate -var-create error for optzd ptr to struct

[Pedro Alves]

On 04/05/2016 07:50 PM, Don Breazeal wrote:
> Hi Yao,
> 
> On 4/5/2016 5:52 AM, Yao Qi wrote:
>> Don Breazeal <donb@codesourcery.com> writes:
> 
>>> +      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?
> 
> Of course, that makes more sense, thanks.
> 
>> 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.
> 
> I've done a more thorough audit of the call sites for value_optimized_out
> than I did previously, and the only places where an enclosing TRY/CATCH can
> be removed are the two you name.  There is one other place where it is
> called inside a TRY/CATCH, but there are other functions that could throw
> errors called there as well.
> 
> I will create a follow-up patch.
> 
> I changed this patch as you suggest above, as well as changing
> RETURN_MASK_ERROR to RETURN_MASK_ALL.  The TRY/CATCH blocks that are
> going to be removed use RETURN_MASK_ALL, and I thought that this patch
> should maintain the same level of coverage.

Please don't.  A RETURN_MASK_ALL swallows Ctrl-C/QUIT, and that's almost
always a bug.  The cases you mention translate a QUIT to a python/scheme
exception, which is not the same as just swallowing the exception.

Thanks,
Pedro Alves

Re: [PATCH] Eliminate -var-create error for optzd ptr to struct

[Don Breazeal]

On 4/5/2016 12:00 PM, Pedro Alves wrote:
> On 04/05/2016 07:50 PM, Don Breazeal wrote:
>> Hi Yao,
>>
>> On 4/5/2016 5:52 AM, Yao Qi wrote:
>>> Don Breazeal <donb@codesourcery.com> writes:
>>
>>>> +      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?
>>
>> Of course, that makes more sense, thanks.
>>
>>> 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.
>>
>> I've done a more thorough audit of the call sites for value_optimized_out
>> than I did previously, and the only places where an enclosing TRY/CATCH can
>> be removed are the two you name.  There is one other place where it is
>> called inside a TRY/CATCH, but there are other functions that could throw
>> errors called there as well.
>>
>> I will create a follow-up patch.
>>
>> I changed this patch as you suggest above, as well as changing
>> RETURN_MASK_ERROR to RETURN_MASK_ALL.  The TRY/CATCH blocks that are
>> going to be removed use RETURN_MASK_ALL, and I thought that this patch
>> should maintain the same level of coverage.
> 
> Please don't.  A RETURN_MASK_ALL swallows Ctrl-C/QUIT, and that's almost
> always a bug.  The cases you mention translate a QUIT to a python/scheme
> exception, which is not the same as just swallowing the exception.

Patch below changes that back.  Pedro, thanks for clarifying.

--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 checks value->optimized_out.  If we can't
definitively say that the value is optimized out, then we assume
it is not.

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-05  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): If a memory access error occurs,
	just check vaue->optimized_out.


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

diff --git a/gdb/value.c b/gdb/value.c
index 8268b08..8a210e7 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,17 @@ 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_ALL)
+	{
+	  /* Fall back to checking value->optimized_out.  */
+	}
+      END_CATCH
+    }
 
   return !VEC_empty (range_s, value->optimized_out);
 }
-- 
1.8.1.1

Re: [PATCH] Eliminate -var-create error for optzd ptr to struct

[Yao Qi]

Don Breazeal <donb@codesourcery.com> writes:

>> Please don't.  A RETURN_MASK_ALL swallows Ctrl-C/QUIT, and that's almost
>> always a bug.  The cases you mention translate a QUIT to a python/scheme
>> exception, which is not the same as just swallowing the exception.
>
> Patch below changes that back.  Pedro, thanks for clarifying.
>

No, it doesn't.

> @@ -1433,7 +1434,17 @@ 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_ALL)

It should be RETURN_MASK_ERROR.

> +	{
> +	  /* Fall back to checking value->optimized_out.  */
> +	}
> +      END_CATCH
> +    }

Otherwise, patch is good to me.

-- 
Yao (齐尧)

Re: [PATCH] Eliminate -var-create error for optzd ptr to struct

[Don Breazeal]

On 4/6/2016 2:04 AM, Yao Qi wrote:
> Don Breazeal <donb@codesourcery.com> writes:
> 
>>> Please don't.  A RETURN_MASK_ALL swallows Ctrl-C/QUIT, and that's almost
>>> always a bug.  The cases you mention translate a QUIT to a python/scheme
>>> exception, which is not the same as just swallowing the exception.
>>
>> Patch below changes that back.  Pedro, thanks for clarifying.
>>
> 
> No, it doesn't.
> 
>> @@ -1433,7 +1434,17 @@ 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_ALL)
> 
> It should be RETURN_MASK_ERROR.

Sorry about that.
/me shakes head at self for goofing up the easy stuff.

> 
>> +	{
>> +	  /* Fall back to checking value->optimized_out.  */
>> +	}
>> +      END_CATCH
>> +    }
> 
> Otherwise, patch is good to me.
> 
Thanks Yao.  This is now corrected and pushed in.

Question: in light of Pedro's comments regarding
gdbscm_value_optimized_out_p and valpy_get_is_optimized_out:

> A RETURN_MASK_ALL swallows Ctrl-C/QUIT, and that's almost
> always a bug.  The cases you mention translate a QUIT to
> a python/scheme exception, which is not the same as just
> swallowing the exception.

Would you still like for me to follow up with a patch to remove the
TRY/CATCH blocks around the calls to value_optimized_out in those two
functions?  Or do we want to leave it as-is so that the QUIT handling
remains unchanged?

Thanks
--Don

Re: [PATCH] Eliminate -var-create error for optzd ptr to struct

[Pedro Alves]

On 04/06/2016 10:41 PM, Don Breazeal wrote:
> On 4/6/2016 2:04 AM, Yao Qi wrote:

> Question: in light of Pedro's comments regarding
> gdbscm_value_optimized_out_p and valpy_get_is_optimized_out:
> 
>> A RETURN_MASK_ALL swallows Ctrl-C/QUIT, and that's almost
>> always a bug.  The cases you mention translate a QUIT to
>> a python/scheme exception, which is not the same as just
>> swallowing the exception.
> 
> Would you still like for me to follow up with a patch to remove the
> TRY/CATCH blocks around the calls to value_optimized_out in those two
> functions?  Or do we want to leave it as-is so that the QUIT handling
> remains unchanged?

Please leave them as is.  We need to translate gdb exceptions to Python/Scheme
exceptions at the gdb <-> extension-language boundaries.  Those gdb
functions in question will be returning to the Python/Scheme runtimes, which
are not prepared to unwind correctly on a gdb exception.

Thanks,
Pedro Alves

Re: [PATCH] Eliminate -var-create error for optzd ptr to struct

[Yao Qi]

On 06/04/16 22:41, Don Breazeal wrote:
> Would you still like for me to follow up with a patch to remove the
> TRY/CATCH blocks around the calls to value_optimized_out in those two
> functions?  Or do we want to leave it as-is so that the QUIT handling
> remains unchanged?

No, I was wrong on that point.  Please leave it as-is.

-- 
Yao (齐尧)

Re: [PATCH] Eliminate -var-create error for optzd ptr to struct

[Luis Machado]

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.

Re: [PATCH] Eliminate -var-create error for optzd ptr to struct

[Don Breazeal]

On 2/23/2016 5:14 PM, Gustavo, Luis wrote:
> 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?

Yes.  I should have documented that in the ChangeLog.

> 
>>   	  && 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.

Thanks for the review, Luis.

> 
> 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.
> 
The main problem so far has been to get the compiler to optimize out the
variables that I want it to optimize out, with a target that is generic
enough that I can generate some assembly code that will run on something
other than a specific version of a CPU.  Trial and error.

Re: [PATCH] Eliminate -var-create error for optzd ptr to struct

[Pedro Alves]

On 02/24/2016 04:31 PM, Don Breazeal wrote:
> The main problem so far has been to get the compiler to optimize out the
> variables that I want it to optimize out, with a target that is generic
> enough that I can generate some assembly code that will run on something
> other than a specific version of a CPU.  Trial and error.

Sounds like a job for the testsuite's dwarf assembler?

Thanks,
Pedro Alves

Re: [PATCH] Eliminate -var-create error for optzd ptr to struct

[Yao Qi]

Don Breazeal <donb@codesourcery.com> writes:

>>> @@ -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?
>
> Yes.  I should have documented that in the ChangeLog.

If it is just a format change, you can move it to a separate patch, and
commit it as obvious.  Don't mix format change with your bug fix patch.

-- 
Yao (齐尧)

Re: [PATCH] Eliminate -var-create error for optzd ptr to struct

[Don Breazeal]

On 3/29/2016 5:01 AM, Yao Qi wrote:
> Don Breazeal <donb@codesourcery.com> writes:
> 
>>>> @@ -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?
>>
>> Yes.  I should have documented that in the ChangeLog.
> 
> If it is just a format change, you can move it to a separate patch, and
> commit it as obvious.  Don't mix format change with your bug fix patch.
> 

Hi Yao,
Here is the patch with the formatting change removed, and with the more
concise patch description posted most recent patchset.
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.

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.

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

	* gdb/value.c (value_actual_type): Ignore the 'print object
	  on' setting if the object is a pointer to or reference to
	  a structure.

---
 gdb/value.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/gdb/value.c b/gdb/value.c
index 738b2b2..95bfdb2 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;

-- 
1.8.1.1

Re: [PATCH] Eliminate -var-create error for optzd ptr to struct

[Yao Qi]

Don Breazeal <donb@codesourcery.com> writes:

> Tested on bare-metal powerpc board with Linux x86 host.
>

Please run regression test on x86-linux.  If the test is regression
free, the patch is good to me.

> gdb/ChangeLog:
> 2016-03-29  Don Breazeal  <donb@codesourcery.com>
>
> 	* gdb/value.c (value_actual_type): Ignore the 'print object
> 	  on' setting if the object is a pointer to or reference to
> 	  a structure.

We should mention the object is optimized out.

-- 
Yao (齐尧)

Re: [PATCH] Eliminate -var-create error for optzd ptr to struct

[Don Breazeal]

Hi Yao,

Thanks for the review.

> Please run regression test on x86-linux.  If the test is regression
> free, the patch is good to me.

Well, that was a good call, the test was not regression-free.  There
were failures in gdb.mi/mi-var-list-children-invalid-grandchild.exp.

The test resulted in a memory access error in the
call to value_optimized_out that I had added.  Before my change
there was a memory access error caught in value_rtti_indirect_type,
which returned NULL in that case.  The fix was to catch and ignore
errors from value_optimized_out.

Details:
The test had a pointer to a structure (p_outer), and the structure
contained a pointer to another structure (p_outer->inner).  The
p_outer pointer was set to 0x0, and -var-create and -var-list-children
were called for p_outer.

With 'set print object' set to 'on', GDB wants to check the actual
(rtti) type of p_outer->inner for -var-list-children.  Without my change,
value_rtti_indirect_type handled the memory access error when it
dereferenced p_outer (0x0).  With my change, value_optimized_out
threw an error trying to get the value of p_outer->inner, since
p_outer == 0x0.

The fix is to catch errors from value_optimized_out.  If we get
an error, then we can't tell if the value is optimized out and
we default to 'not optimized out'.  We let value_rtti_indirect_type
handle the memory error.

I assume that I didn't see this with my bare-metal testing because
it wasn't an error to access address 0x0.  I'll be sure to keep that
in mind in future testing.


Updated patch, patch description, and ChangeLog below.
OK with these changes?

BTW I will hold off pushing in the corresponding test until this
patch is finalized, to avoid introducing new failures.

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.

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'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-01  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.

---
 gdb/value.c | 27 +++++++++++++++++++++------
 1 file changed, 21 insertions(+), 6 deletions(-)

diff --git a/gdb/value.c b/gdb/value.c
index 8268b08..018896e 100644
--- a/gdb/value.c
+++ b/gdb/value.c
@@ -1192,6 +1192,7 @@ value_actual_type (struct value *value, int resolve_simple_types,
 {
   struct value_print_options opts;
   struct type *result;
+  int value_optzd_out;
 
   get_user_print_options (&opts);
 
@@ -1200,12 +1201,26 @@ value_actual_type (struct value *value, int resolve_simple_types,
   result = value_type (value);
   if (opts.objectprint)
     {
-      /* 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 (check_typedef (TYPE_TARGET_TYPE (result)))
-	     == TYPE_CODE_STRUCT)
+      TRY
+	{
+	  value_optzd_out = value_optimized_out (value);
+	}
+      CATCH (ex, RETURN_MASK_ERROR)
+	{
+	  /* If we get an error, assume the value is not optimized out.
+	     If we call value_rtti_indirect_type, it will handle any
+	     errors there; otherwise it won't matter.  */
+	  value_optzd_out = 0;
+	}
+      END_CATCH
+
+       /* 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 (check_typedef (TYPE_TARGET_TYPE (result)))
+	     == TYPE_CODE_STRUCT
+	   && !value_optzd_out)
         {
           struct type *real_type;
 
-- 
1.8.1.1

Re: [PATCH] Eliminate -var-create error for optzd ptr to struct

[Yao Qi]

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.

-- 
Yao (齐尧)

Re: [PATCH] Eliminate -var-create error for optzd ptr to struct

[Don Breazeal]

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.
--Don

Re: [PATCH] Eliminate -var-create error for optzd ptr to struct

[Don Breazeal]

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(-)

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);
 }
-- 
1.8.1.1