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
next prev parent 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