* [PATCH] [gdb/exp] Fix cast handling for indirection
@ 2024-05-02 15:49 Tom de Vries
2024-05-03 2:31 ` Kevin Buettner
0 siblings, 1 reply; 10+ messages in thread
From: Tom de Vries @ 2024-05-02 15:49 UTC (permalink / raw)
To: gdb-patches
Consider a test-case compiled without debug info, containing:
...
char a = 'a';
char *
a_loc (void)
{
return &a;
}
...
We get:
...
(gdb) p (char)*a_loc ()
Cannot access memory at address 0x10
...
There's a bug in unop_ind_base_operation::evaluate that evaluates
"(char)*a_loc ()" the same as:
...
(gdb) p (char)*(char)a_loc ()
Cannot access memory at address 0x10
...
Fix this by instead evaluating it the same as:
...
(gdb) p (char)*(char *)a_loc ()
$1 = 97 'a'
...
Tested on x86_64-linux.
PR exp/31693
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31693
---
gdb/expop.h | 8 +++--
gdb/testsuite/gdb.base/cast-indirection.c | 31 ++++++++++++++++
gdb/testsuite/gdb.base/cast-indirection.exp | 40 +++++++++++++++++++++
3 files changed, 76 insertions(+), 3 deletions(-)
create mode 100644 gdb/testsuite/gdb.base/cast-indirection.c
create mode 100644 gdb/testsuite/gdb.base/cast-indirection.exp
diff --git a/gdb/expop.h b/gdb/expop.h
index b81e228c07e..1967d9779b7 100644
--- a/gdb/expop.h
+++ b/gdb/expop.h
@@ -1513,9 +1513,11 @@ class unop_ind_base_operation
struct expression *exp,
enum noside noside) override
{
- if (expect_type != nullptr && expect_type->code () == TYPE_CODE_PTR)
- expect_type = check_typedef (expect_type)->target_type ();
- value *val = std::get<0> (m_storage)->evaluate (expect_type, exp, noside);
+ struct type *pointer_to_expect_type = (expect_type != nullptr
+ ? lookup_pointer_type (expect_type)
+ : nullptr);
+ value *val
+ = std::get<0> (m_storage)->evaluate (pointer_to_expect_type, exp, noside);
return eval_op_ind (expect_type, exp, noside, val);
}
diff --git a/gdb/testsuite/gdb.base/cast-indirection.c b/gdb/testsuite/gdb.base/cast-indirection.c
new file mode 100644
index 00000000000..d59c66ead35
--- /dev/null
+++ b/gdb/testsuite/gdb.base/cast-indirection.c
@@ -0,0 +1,31 @@
+/* This testcase is part of GDB, the GNU debugger.
+
+ Copyright 2024 Free Software Foundation, Inc.
+
+ This program is free software; you can redistribute it and/or modify
+ it under the terms of the GNU General Public License as published by
+ the Free Software Foundation; either version 3 of the License, or
+ (at your option) any later version.
+
+ This program is distributed in the hope that it will be useful,
+ but WITHOUT ANY WARRANTY; without even the implied warranty of
+ MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ GNU General Public License for more details.
+
+ You should have received a copy of the GNU General Public License
+ along with this program. If not, see <http://www.gnu.org/licenses/>. */
+
+char a = 'a';
+
+char *
+a_loc (void)
+{
+ return &a;
+}
+
+int
+main (void)
+{
+ int res = *a_loc () == 'a';
+ return !res;
+}
diff --git a/gdb/testsuite/gdb.base/cast-indirection.exp b/gdb/testsuite/gdb.base/cast-indirection.exp
new file mode 100644
index 00000000000..d2c6d58e3ca
--- /dev/null
+++ b/gdb/testsuite/gdb.base/cast-indirection.exp
@@ -0,0 +1,40 @@
+# Copyright (C) 2024 Free Software Foundation, Inc.
+
+# This program is free software; you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation; either version 3 of the License, or
+# (at your option) any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program. If not, see <http://www.gnu.org/licenses/>.
+
+# Check that "p (char)*a_loc ()" is handled as "p (char)*(char *)a_loc ()".
+
+standard_testfile
+
+if { [prepare_for_testing "failed to prepare" $testfile $srcfile \
+ {nodebug}] == -1} {
+ return -1
+}
+
+if ![runto_main] {
+ return -1
+}
+
+gdb_test "p a_loc ()" \
+ "'a_loc' has unknown return type; cast the call to its declared return type"
+
+gdb_test "p *a_loc ()" \
+ "'a_loc' has unknown return type; cast the call to its declared return type"
+
+gdb_test "p *(char *)a_loc ()" " = 97 'a'"
+
+gdb_test "p (char)*(char *)a_loc ()" " = 97 'a'"
+
+# Regression test for PR31693.
+gdb_test "p (char)*a_loc ()" " = 97 'a'"
base-commit: 5ce0e02478cc79a260c7e29822450284a32b9b12
--
2.35.3
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH] [gdb/exp] Fix cast handling for indirection
2024-05-02 15:49 [PATCH] [gdb/exp] Fix cast handling for indirection Tom de Vries
@ 2024-05-03 2:31 ` Kevin Buettner
2024-05-03 7:37 ` Tom de Vries
2024-05-03 15:27 ` Tom Tromey
0 siblings, 2 replies; 10+ messages in thread
From: Kevin Buettner @ 2024-05-03 2:31 UTC (permalink / raw)
To: Tom de Vries; +Cc: gdb-patches
On Thu, 2 May 2024 17:49:02 +0200
Tom de Vries <tdevries@suse.de> wrote:
> Consider a test-case compiled without debug info, containing:
> ...
> char a = 'a';
>
> char *
> a_loc (void)
> {
> return &a;
> }
> ...
>
> We get:
> ...
> (gdb) p (char)*a_loc ()
> Cannot access memory at address 0x10
> ...
>
> There's a bug in unop_ind_base_operation::evaluate that evaluates
> "(char)*a_loc ()" the same as:
> ...
> (gdb) p (char)*(char)a_loc ()
This surprised me. I would have thought that the evaluation would
have been:
(char)*(int)a_loc ()
...due to the fact that functions lacking an explicit return type
return 'int' in traditional C.
> Cannot access memory at address 0x10
> ...
>
> Fix this by instead evaluating it the same as:
> ...
> (gdb) p (char)*(char *)a_loc ()
> $1 = 97 'a'
> ...
>
> Tested on x86_64-linux.
>
> PR exp/31693
> Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31693
Aside from the (possible) nit in the commit log that I mention
above, the patch and test case look good to me.
Approved-by: Kevin Buettner <kevinb@redhat.com>
Kevin
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH] [gdb/exp] Fix cast handling for indirection
2024-05-03 2:31 ` Kevin Buettner
@ 2024-05-03 7:37 ` Tom de Vries
2024-05-03 15:27 ` Tom Tromey
1 sibling, 0 replies; 10+ messages in thread
From: Tom de Vries @ 2024-05-03 7:37 UTC (permalink / raw)
To: Kevin Buettner; +Cc: gdb-patches
On 5/3/24 04:31, Kevin Buettner wrote:
> On Thu, 2 May 2024 17:49:02 +0200
> Tom de Vries <tdevries@suse.de> wrote:
>
>> Consider a test-case compiled without debug info, containing:
>> ...
>> char a = 'a';
>>
>> char *
>> a_loc (void)
>> {
>> return &a;
>> }
>> ...
>>
>> We get:
>> ...
>> (gdb) p (char)*a_loc ()
>> Cannot access memory at address 0x10
>> ...
>>
>> There's a bug in unop_ind_base_operation::evaluate that evaluates
>> "(char)*a_loc ()" the same as:
>> ...
>> (gdb) p (char)*(char)a_loc ()
>
Hi Kevin,
thanks for the review.
> This surprised me. I would have thought that the evaluation would
> have been:
>
> (char)*(int)a_loc ()
>
> ...due to the fact that functions lacking an explicit return type
> return 'int' in traditional C.
>
Default-to-int was my first guess, but after debugging and investigating
the code in unop_ind_base_operation::evaluate, I realized that the cast
(passed in expect_type) is passed unmodified to the dereferenced expression.
I used this in the test-case, by changing the cast from int to char, to
maximize the changes that the PR will produce an incorrect pointer.
>> Cannot access memory at address 0x10
>> ...
>>
>> Fix this by instead evaluating it the same as:
>> ...
>> (gdb) p (char)*(char *)a_loc ()
>> $1 = 97 'a'
>> ...
>>
>> Tested on x86_64-linux.
>>
>> PR exp/31693
>> Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31693
>
> Aside from the (possible) nit in the commit log that I mention
> above, the patch and test case look good to me.
>
> Approved-by: Kevin Buettner <kevinb@redhat.com>
>
Thanks, pushed unmodified.
- Tom
> Kevin
>
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH] [gdb/exp] Fix cast handling for indirection
2024-05-03 2:31 ` Kevin Buettner
2024-05-03 7:37 ` Tom de Vries
@ 2024-05-03 15:27 ` Tom Tromey
2024-05-03 16:04 ` Pedro Alves
1 sibling, 1 reply; 10+ messages in thread
From: Tom Tromey @ 2024-05-03 15:27 UTC (permalink / raw)
To: Kevin Buettner; +Cc: Tom de Vries, gdb-patches
>>>>> "Kevin" == Kevin Buettner <kevinb@redhat.com> writes:
>> char *
>> a_loc (void)
Kevin> This surprised me. I would have thought that the evaluation would
Kevin> have been:
Kevin> (char)*(int)a_loc ()
Kevin> ...due to the fact that functions lacking an explicit return type
Kevin> return 'int' in traditional C.
Here the function actually returns char*, it's just the debug info is
missing.
Normally users should have written:
print *(char *) a_loc()
here, at least after the changes a while ago to require a cast of the
return type here. Longer ago, debuginfo-less functions did default to
int return in gdb, but Pedro (I think) changed this a while back.
I was wondering if this patch causes gdb to accept some weird things
that might have been rejected in the past, by introducing a hidden cast.
Maybe print (char) *85732 does something surprising now. I'm not
entirely sure if that's bad.
Tom
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH] [gdb/exp] Fix cast handling for indirection
2024-05-03 15:27 ` Tom Tromey
@ 2024-05-03 16:04 ` Pedro Alves
2024-05-03 17:30 ` Kevin Buettner
0 siblings, 1 reply; 10+ messages in thread
From: Pedro Alves @ 2024-05-03 16:04 UTC (permalink / raw)
To: Tom Tromey, Kevin Buettner; +Cc: Tom de Vries, gdb-patches
On 2024-05-03 16:27, Tom Tromey wrote:
> Here the function actually returns char*, it's just the debug info is
> missing.
>
> Normally users should have written:
>
> print *(char *) a_loc()
>
> here, at least after the changes a while ago to require a cast of the
> return type here. Longer ago, debuginfo-less functions did default to
> int return in gdb, but Pedro (I think) changed this a while back.
Yes.
>
> I was wondering if this patch causes gdb to accept some weird things
> that might have been rejected in the past, by introducing a hidden cast.
> Maybe print (char) *85732 does something surprising now. I'm not
> entirely sure if that's bad.
I am totally surprised that:
+# Regression test for PR31693.
+gdb_test "p (char)*a_loc ()" " = 97 'a'"
this actually works, instead of telling the user:
"'a_loc' has unknown return type; cast the call to its declared return type"
It seems like a misfeature to me to assume that "char *" is the right type.
Thus, I don't agree with the patch.
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH] [gdb/exp] Fix cast handling for indirection
2024-05-03 16:04 ` Pedro Alves
@ 2024-05-03 17:30 ` Kevin Buettner
2024-05-03 23:17 ` Pedro Alves
0 siblings, 1 reply; 10+ messages in thread
From: Kevin Buettner @ 2024-05-03 17:30 UTC (permalink / raw)
To: Pedro Alves; +Cc: gdb-patches, Tom Tromey, Tom de Vries
On Fri, 3 May 2024 17:04:41 +0100
Pedro Alves <pedro@palves.net> wrote:
> > I was wondering if this patch causes gdb to accept some weird things
> > that might have been rejected in the past, by introducing a hidden cast.
> > Maybe print (char) *85732 does something surprising now. I'm not
> > entirely sure if that's bad.
>
> I am totally surprised that:
>
> +# Regression test for PR31693.
> +gdb_test "p (char)*a_loc ()" " = 97 'a'"
>
> this actually works, instead of telling the user:
>
> "'a_loc' has unknown return type; cast the call to its declared return type"
>
> It seems like a misfeature to me to assume that "char *" is the right type.
>
> Thus, I don't agree with the patch.
Using a GDB built with Tom de Vries's patch, I see:
(gdb) p *a_loc()
'a_loc' has unknown return type; cast the call to its declared return type
This is the same as the pre-patch behavior.
With Tom's patch, GDB now infers the function's return type, based
on the cast:
(gdb) p (char)*a_loc()
$1 = 97 'a'
I like this behavior and certainly find it preferable to the behavior
without his patch:
(gdb) p (char)*a_loc()
Cannot access memory at address 0x4
With regard to doing something like 'print (char) *85732', I
don't see anything surprising...
(gdb) p/d (char *)a_loc()
$1 = 4210692
(I'll use 4210692 in place of 85732.)
Pre-patch:
(gdb) p *4210692
$2 = 97
(gdb) p (char)*4210692
$3 = 97 'a'
With Tom de Vries's patch:
(gdb) p *4210692
$9 = 97
(gdb) p (char)*4210692
$10 = 97 'a'
Kevin
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH] [gdb/exp] Fix cast handling for indirection
2024-05-03 17:30 ` Kevin Buettner
@ 2024-05-03 23:17 ` Pedro Alves
2024-05-03 23:26 ` Pedro Alves
0 siblings, 1 reply; 10+ messages in thread
From: Pedro Alves @ 2024-05-03 23:17 UTC (permalink / raw)
To: Kevin Buettner; +Cc: gdb-patches, Tom Tromey, Tom de Vries
On 2024-05-03 18:30, Kevin Buettner wrote:
> On Fri, 3 May 2024 17:04:41 +0100
> Pedro Alves <pedro@palves.net> wrote:
>
>>> I was wondering if this patch causes gdb to accept some weird things
>>> that might have been rejected in the past, by introducing a hidden cast.
>>> Maybe print (char) *85732 does something surprising now. I'm not
>>> entirely sure if that's bad.
>>
>> I am totally surprised that:
>>
>> +# Regression test for PR31693.
>> +gdb_test "p (char)*a_loc ()" " = 97 'a'"
>>
>> this actually works, instead of telling the user:
>>
>> "'a_loc' has unknown return type; cast the call to its declared return type"
>>
>> It seems like a misfeature to me to assume that "char *" is the right type.
>>
>> Thus, I don't agree with the patch.
>
> Using a GDB built with Tom de Vries's patch, I see:
>
> (gdb) p *a_loc()
> 'a_loc' has unknown return type; cast the call to its declared return type
>
> This is the same as the pre-patch behavior.
>
> With Tom's patch, GDB now infers the function's return type, based
> on the cast:
>
> (gdb) p (char)*a_loc()
> $1 = 97 'a'
>
But that is not what GDB told you to do. It told you to cast the _call_,
not the result of de-referencing the result of the call.
It is telling cast to the declared return type, which is "char *". I.e.,
it is telling you to write:
(gdb) p *(char *)a_loc()
See 7022349d5c86 ("Stop assuming no-debug-info functions return int").
This cast here:
(gdb) p (char)*a_loc()
... should not affect the call's return type. That is decided before
the * operator is involved. In the same way, this:
(gdb) p (long long)*a_loc()
should not result in gdb assuming that a_loc() returns a "long long *",
that it wrong. It should still error out with
'a_loc' has unknown return type; cast the call to its declared return type
and so the user should write:
(gdb) p (long long) *(char *)a_loc()
and then with this last expression a proper sign extension is applied when
char is converted to long long, if char is signed. I.e., in steps:
1: (char *)a_loc() -> call, and get char * return value
2: *(char *)a_loc() -> deref, and get char value
3: (long long) *(char *)a_loc() -> sign extend char value -> long long value
> I like this behavior and certainly find it preferable to the behavior
> without his patch:
>
> (gdb) p (char)*a_loc()
> Cannot access memory at address 0x4
That's not what I am suggesting.
Pedro Alves
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH] [gdb/exp] Fix cast handling for indirection
2024-05-03 23:17 ` Pedro Alves
@ 2024-05-03 23:26 ` Pedro Alves
2024-05-06 0:54 ` Kevin Buettner
0 siblings, 1 reply; 10+ messages in thread
From: Pedro Alves @ 2024-05-03 23:26 UTC (permalink / raw)
To: Kevin Buettner; +Cc: gdb-patches, Tom Tromey, Tom de Vries
On 2024-05-04 00:17, Pedro Alves wrote:
> On 2024-05-03 18:30, Kevin Buettner wrote:
>> On Fri, 3 May 2024 17:04:41 +0100
>> Pedro Alves <pedro@palves.net> wrote:
>>
>>>> I was wondering if this patch causes gdb to accept some weird things
>>>> that might have been rejected in the past, by introducing a hidden cast.
>>>> Maybe print (char) *85732 does something surprising now. I'm not
>>>> entirely sure if that's bad.
>>>
>>> I am totally surprised that:
>>>
>>> +# Regression test for PR31693.
>>> +gdb_test "p (char)*a_loc ()" " = 97 'a'"
>>>
>>> this actually works, instead of telling the user:
>>>
>>> "'a_loc' has unknown return type; cast the call to its declared return type"
>>>
>>> It seems like a misfeature to me to assume that "char *" is the right type.
>>>
>>> Thus, I don't agree with the patch.
>>
>> Using a GDB built with Tom de Vries's patch, I see:
>>
>> (gdb) p *a_loc()
>> 'a_loc' has unknown return type; cast the call to its declared return type
>>
>> This is the same as the pre-patch behavior.
>>
>> With Tom's patch, GDB now infers the function's return type, based
>> on the cast:
>>
>> (gdb) p (char)*a_loc()
>> $1 = 97 'a'
>>
>
> But that is not what GDB told you to do. It told you to cast the _call_,
> not the result of de-referencing the result of the call.
> It is telling cast to the declared return type, which is "char *". I.e.,
> it is telling you to write:
>
> (gdb) p *(char *)a_loc()
>
> See 7022349d5c86 ("Stop assuming no-debug-info functions return int").
>
> This cast here:
>
> (gdb) p (char)*a_loc()
>
> ... should not affect the call's return type. That is decided before
> the * operator is involved. In the same way, this:
>
> (gdb) p (long long)*a_loc()
>
> should not result in gdb assuming that a_loc() returns a "long long *",
> that it wrong. It should still error out with
>
> 'a_loc' has unknown return type; cast the call to its declared return type
>
> and so the user should write:
>
> (gdb) p (long long) *(char *)a_loc()
>
> and then with this last expression a proper sign extension is applied when
> char is converted to long long, if char is signed. I.e., in steps:
>
> 1: (char *)a_loc() -> call, and get char * return value
> 2: *(char *)a_loc() -> deref, and get char value
> 3: (long long) *(char *)a_loc() -> sign extend char value -> long long value
>
I kind of emphasized the sign extension part above, but to be clear, with
(gdb) p (long long)*a_loc()
and gdb assuming that means a_loc returns "long long *", gdb incorrectly reads a
64-bit value off of the pointer address, which is totally bogus and would not
be what gdb would do if it had debug info for a_loc(), in which case GDB would
know that it returns char *, and thus would deref only one byte and behave like
described above in the 1: 2: 3: steps. The behavior of the expression should not
change like that depending on whether you have debug info. Thus, GDB should error
out.
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH] [gdb/exp] Fix cast handling for indirection
2024-05-03 23:26 ` Pedro Alves
@ 2024-05-06 0:54 ` Kevin Buettner
2024-05-06 6:52 ` Tom de Vries
0 siblings, 1 reply; 10+ messages in thread
From: Kevin Buettner @ 2024-05-06 0:54 UTC (permalink / raw)
To: Pedro Alves; +Cc: gdb-patches, Tom Tromey, Tom de Vries
On Sat, 4 May 2024 00:26:49 +0100
Pedro Alves <pedro@palves.net> wrote:
> I kind of emphasized the sign extension part above, but to be clear, with
>
> (gdb) p (long long)*a_loc()
>
> and gdb assuming that means a_loc returns "long long *", gdb incorrectly reads a
> 64-bit value off of the pointer address, which is totally bogus and would not
> be what gdb would do if it had debug info for a_loc(), in which case GDB would
> know that it returns char *, and thus would deref only one byte and behave like
> described above in the 1: 2: 3: steps. The behavior of the expression should not
> change like that depending on whether you have debug info. Thus, GDB should error
> out.
This argument is compelling. You've convinced me.
Kevin
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH] [gdb/exp] Fix cast handling for indirection
2024-05-06 0:54 ` Kevin Buettner
@ 2024-05-06 6:52 ` Tom de Vries
0 siblings, 0 replies; 10+ messages in thread
From: Tom de Vries @ 2024-05-06 6:52 UTC (permalink / raw)
To: Kevin Buettner, Pedro Alves; +Cc: gdb-patches, Tom Tromey
On 5/6/24 02:54, Kevin Buettner wrote:
> On Sat, 4 May 2024 00:26:49 +0100
> Pedro Alves <pedro@palves.net> wrote:
>
>> I kind of emphasized the sign extension part above, but to be clear, with
>>
>> (gdb) p (long long)*a_loc()
>>
>> and gdb assuming that means a_loc returns "long long *", gdb incorrectly reads a
>> 64-bit value off of the pointer address, which is totally bogus and would not
>> be what gdb would do if it had debug info for a_loc(), in which case GDB would
>> know that it returns char *, and thus would deref only one byte and behave like
>> described above in the 1: 2: 3: steps. The behavior of the expression should not
>> change like that depending on whether you have debug info. Thus, GDB should error
>> out.
>
> This argument is compelling. You've convinced me.
>
And me as wel.
I've submitted a patch
(https://sourceware.org/pipermail/gdb-patches/2024-May/208843.html ) to
redo the fix.
Thanks,
- Tom
^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2024-05-06 6:51 UTC | newest]
Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2024-05-02 15:49 [PATCH] [gdb/exp] Fix cast handling for indirection Tom de Vries
2024-05-03 2:31 ` Kevin Buettner
2024-05-03 7:37 ` Tom de Vries
2024-05-03 15:27 ` Tom Tromey
2024-05-03 16:04 ` Pedro Alves
2024-05-03 17:30 ` Kevin Buettner
2024-05-03 23:17 ` Pedro Alves
2024-05-03 23:26 ` Pedro Alves
2024-05-06 0:54 ` Kevin Buettner
2024-05-06 6:52 ` Tom de Vries
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).