This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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

Oops, sorry.  It is a private bug -- not for any good reason AFAICT, but
I can't change it.

Here is Jan's one-line reproducer:

echo 'char s[]="a";main(){return s[0]=='"'a';}"|gcc -o v -x c - -g;./v;echo $?;~/redhat/gdb-6.8/gdb/gdb -nx -write ./v -ex 'set var s="b"' -ex q;./v;echo $?

Tom> +		result = allocate_value (expect_type);
Tom> +		memcpy (value_contents_raw (result), obstack_base (&output),
Tom> +			obstack_object_size (&output));

Yao> Compared with value_cstring, the difference is that expect_type is used
Yao> here, while type used in value_cstring is got from lookup_array_range_type.

Yao> struct type *stringtype
Yao>     = lookup_array_range_type (char_type, lowbound, highbound + lowbound
Yao> - 1);

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.

Tom


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]