This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: RFC: fix `gdb -write' case
>>>>> "Yao" == Yao Qi <yao@codesourcery.com> writes:
Tom> https://bugzilla.redhat.com/show_bug.cgi?id=696148
Yao> FYI, I can't access this bug. I am told "You are not authorized to
Yao> access bug #696148."
In that Bug I made a comment
# evaluate_subexp_c->OP_STRING ignores expect_type, GDB then tries to convert
# the non-matching type using malloc.
which I advocate below.
On Mon, 09 May 2011 16:53:38 +0200, Tom Tromey wrote:
> Yao> Any difference on these two type variables (expect_type vs. stringtype)?
>
> Yes. You can wind up with a different "char" type following the logic
> in c-lang.c. In this case some higher level will try to cast the string
> to the correct type, which will try to force it to memory, leading to
> the bad result.
>
> The checks in the patch are intended to ensure that the expected type
> isn't "too weird" -- that we don't do something nonsensical.
The approach you took is not in the style of current GDB:
#include <wchar.h>
short a_short[2];
long a_long[2];
char a_char[3];
wchar_t a_wchar[3];
int main (void) { return 0; }
# With gcc only - without libstdc++ linked - GDB complains despite the code
# compiled and runs fine; but that is a different Bug.
# (gdb) p U"x"
# No type named char32_t.
g++ -g
(gdb) start
(gdb) set a_short={1L,2LL}
(gdb) p a_short
$1 = {1, 2}
(gdb) ptype a_short
type = short [2]
(gdb) set a_long={1L,2LL}
(gdb) p a_long
$2 = {1, 2}
(gdb) ptype a_long
type = long [2]
(gdb) set a_char=U"x"
expected type of string constant has wrong character width
(gdb) set a_wchar="x"
expected type of string constant has wrong character width
(gdb)
I believe if GDB adjusts the short/long types shouldn't it adjust also
char/whar_t types? That is now the user must know the type of string in
advance which wasn't the case for arrays before.
But it is not a real regression as GDB had not supported Unicode strings.
This is why I made the comment above.
Thanks,
Jan