Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: "Andrew Burgess" <aburgess@broadcom.com>
To: "Pedro Alves" <palves@redhat.com>
Cc: gdb-patches@sourceware.org
Subject: Re: [COMMIT PATCH] value_bits_valid: Fix latent bug.
Date: Fri, 05 Jul 2013 15:20:00 -0000	[thread overview]
Message-ID: <51D6E441.4040709@broadcom.com> (raw)
In-Reply-To: <51D6E0EB.3040006@redhat.com>

On 05/07/2013 4:06 PM, Pedro Alves wrote:
> On 07/05/2013 03:42 PM, Andrew Burgess wrote:
>> On 04/07/2013 5:09 PM, Pedro Alves wrote:
>>> Doing something else, I factored out the bits of the value_bits_valid
>>> function that actually handle the check_validity hook, and
>>> surprisingly found out that the result was misbehaving.  Turns out
>>> value_bits_valid has a latent bug.  If the value is not lval_computed,
>>> or doesn't have a check_validity hook, then we should assume the value
>>> is entirely valid, not invalid.  This is currently masked by the
>>> value->optimized_out check -- I ran the testsuite with a gdb_assert(0)
>>> inserted in place of that return being touched by the patch, and it
>>> never triggers.
>>>
>>> Tested on x86_64 Fedora 17.
>>>
>>> gdb/
>>> 2013-07-04  Pedro Alves  <palves@redhat.com>
>>>
>>> 	* value.c (value_bits_valid): If the value is not lval_computed,
>>> 	or doesn't have a check_validity hook, assume the value is entirely
>>> 	valid.
>>> ---
>>>  gdb/value.c |    2 +-
>>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/gdb/value.c b/gdb/value.c
>>> index ce4b13a..353f62a 100644
>>> --- a/gdb/value.c
>>> +++ b/gdb/value.c
>>> @@ -1086,7 +1086,7 @@ value_bits_valid (const struct value *value, int offset, int length)
>>>      return 1;
>>>    if (value->lval != lval_computed
>>>        || !value->location.computed.funcs->check_validity)
>>> -    return 0;
>>> +    return 1;
>>>    return value->location.computed.funcs->check_validity (value, offset,
>>>  							 length);
>>>  }
>>>
>>
>> There's a small issue with this patch, in the case of an optimized_out,
>> non-computed value we now report that the bits are valid when they
>> should be invalid.
> 
> Whoops...
> 
>> Patch below applies on top of the above and fixes both the original
>> issue Pedro spotted, and fixes the non-computed issue.
>>
>> Ok to apply?
>>
>> Thanks,
>> Andrew
>>
>>
>> gdb/ChangeLog
>>
>> 2013-07-05  Andrew Burgess  <aburgess@broadcom.com>
>>
>> 	* value.c (value_bits_valid): If the value is not lval_computed
>> 	then the answer is in the optimized_out flag, otherwise if we have
>> 	no handler assume bits are valid, if there is a handler use that.
>>
>>
>>
>> diff --git a/gdb/value.c b/gdb/value.c
>> index 353f62a..ca5463b 100644
>> --- a/gdb/value.c
>> +++ b/gdb/value.c
>> @@ -1082,13 +1082,18 @@ value_entirely_optimized_out (const struct value *value)
>>  int
>>  value_bits_valid (const struct value *value, int offset, int length)
>>  {
>> -  if (!value->optimized_out)
>> -    return 1;
>> -  if (value->lval != lval_computed
>> -      || !value->location.computed.funcs->check_validity)
>> -    return 1;
>> -  return value->location.computed.funcs->check_validity (value, offset,
>> -							 length);
>> +  if (value->lval != lval_computed)
>> +    return !value->optimized_out;
>> +  else
>> +    {
>> +      /* Computed value, defer to handler if there is one.  */
>> +      if (!value->location.computed.funcs->check_validity)
>> +	return 1;
> 
> Hmm, in this case we should look at the value->optimized_out
> flag too, I think.  Looks like my patch was bogus afterall,
> and we should just revert it.   Very sorry about that.
> 
> The patch I was originally talking about that exposed the
> issue was:
> 
>  https://github.com/palves/gdb/commit/7143cd119e18d568a5a224ac22f215a96f691624
> 
> but it looks like the value_check_validity function would have to
> check value->optimized_out anyway, so the only difference to
> value_bits_valid would be the assertions...

You're right, except we could imagine a computed value that implements a fetch method, but not a check-validity method, instead it just sets the optimized_out flag.  So, third time lucky, this time,

 - non computed values, and computed values with no check-validity handler just defer to the optimized_out flag.
 - computed values with a handler defer to the handler.

This is a change from the original code, but I think it's a good change, what do you think?

Andrew


gdb/ChangeLog

2013-07-05  Andrew Burgess  <aburgess@broadcom.com>

	* value.c (value_bits_valid): If the value is not lval_computed
	or has no check validity handler then the answer is the
	optimized_out flag, otherwise defer to the handler.

diff --git a/gdb/value.c b/gdb/value.c
index 353f62a..1be1845 100644
--- a/gdb/value.c
+++ b/gdb/value.c
@@ -1082,13 +1082,12 @@ value_entirely_optimized_out (const struct value *value)
 int
 value_bits_valid (const struct value *value, int offset, int length)
 {
-  if (!value->optimized_out)
-    return 1;
   if (value->lval != lval_computed
       || !value->location.computed.funcs->check_validity)
-    return 1;
-  return value->location.computed.funcs->check_validity (value, offset,
-							 length);
+    return !value->optimized_out;
+  else
+    return value->location.computed.funcs->check_validity (value, offset,
+							   length);
 }
 
 int




  reply	other threads:[~2013-07-05 15:20 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-07-04 16:09 Pedro Alves
2013-07-05 14:42 ` Andrew Burgess
2013-07-05 15:06   ` Pedro Alves
2013-07-05 15:20     ` Andrew Burgess [this message]
2013-07-05 18:21       ` Pedro Alves
2013-07-08 10:22         ` Andrew Burgess
2013-07-09  9:54           ` Regression for implptr.exp and pieces.exp [Re: [COMMIT PATCH] value_bits_valid: Fix latent bug.] Jan Kratochvil
2013-07-09 14:16             ` Andrew Burgess
2013-07-24 20:10               ` Jan Kratochvil

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=51D6E441.4040709@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