Memory corruption for host double format different from target double format
Thomas Schwinge
thomas@codesourcery.com
Thu Aug 9 18:19:00 GMT 2012
Hi!
Thanks to the recent memory checking instrastructure (well, it's been
some weeks already...), a memory corruption issue has been uncovered for
configurations where the host double format is not equal to target double
format. I have seen this for SH, but don't believe it really is specific
to SH, it's just that the very most of all GDB targets have host double
format match the target double format.
As I'm not sufficiently experienced with GDB's expressions and type
system, I'd like some help here.
$ install/bin/*-gdb -q -ex 'file [...]/gdb.cp/misc' -ex 'show architecture' -ex 'print (bool)17.93'
Reading symbols from [...]/gdb.cp/misc...done.
The target architecture is set automatically (currently sh2a-or-sh3e)
$1 = true
memory clobbered past end of allocated block
Aborted
sh2a-or-sh3e configures for a 32-bit double format, as opposed to the
"normal" 64-bit double format (which also is the x86_64 host's double
format).
sh-tdep.c:sh_gdbarch_init:
case bfd_mach_sh2a_or_sh3e:
/* doubles on sh2e and sh3e are actually 4 byte. */
set_gdbarch_double_bit (gdbarch, 4 * TARGET_CHAR_BIT);
First and foremost -- is my understanding correct that given this
configuration the expression »(bool) 17.93« then indeed is to be
evaluated in a 32-bit double format, and not in the host's 64-bit double
format?
Our friend Valgrind is able to confirm this memory corruption issue, and
-- as so often -- gives a clue where to begin looking:
$ valgrind -v -- install/bin/*-gdb -q -ex 'file [...]/gdb.cp/misc' -ex 'print (bool)17.93'
[...]
==6509== Invalid write of size 1
==6509== at 0x47FB974: memcpy (mc_replace_strmem.c:497)
==6509== by 0x824D487: floatformat_from_doublest (doublest.c:768)
==6509== by 0x824D78D: store_typed_floating (doublest.c:881)
==6509== by 0x81023DA: value_from_double (value.c:3170)
==6509== by 0x810424F: evaluate_subexp_standard (eval.c:846)
==6509== by 0x82020E3: evaluate_subexp_c (c-lang.c:719)
==6509== by 0x8102975: evaluate_subexp (eval.c:73)
==6509== by 0x810A157: evaluate_subexp_standard (eval.c:2713)
==6509== by 0x82020E3: evaluate_subexp_c (c-lang.c:719)
==6509== by 0x8102975: evaluate_subexp (eval.c:73)
==6509== by 0x8102B02: evaluate_expression (eval.c:148)
==6509== by 0x811EE31: print_command_1 (printcmd.c:966)
==6509== Address 0x8e83bbc is 0 bytes after a block of size 4 alloc'd
==6509== at 0x47F925F: calloc (vg_replace_malloc.c:467)
==6509== by 0x82725B4: xcalloc (common-utils.c:90)
==6509== by 0x82725EA: xzalloc (common-utils.c:100)
==6509== by 0x80FE7AB: allocate_value_contents (value.c:695)
==6509== by 0x80FE7D4: allocate_value (value.c:705)
==6509== by 0x8102383: value_from_double (value.c:3164)
==6509== by 0x810424F: evaluate_subexp_standard (eval.c:846)
==6509== by 0x82020E3: evaluate_subexp_c (c-lang.c:719)
==6509== by 0x8102975: evaluate_subexp (eval.c:73)
==6509== by 0x810A157: evaluate_subexp_standard (eval.c:2713)
==6509== by 0x82020E3: evaluate_subexp_c (c-lang.c:719)
==6509== by 0x8102975: evaluate_subexp (eval.c:73)
[...]
Here is what is happening, in value.c:value_from_double:
struct value *
value_from_double (struct type *type, DOUBLEST num)
{
struct value *val = allocate_value (type);
struct type *base_type = check_typedef (type);
enum type_code code = TYPE_CODE (base_type);
if (code == TYPE_CODE_FLT)
{
store_typed_floating (value_contents_raw (val), base_type, num);
[...]
Breakpoint 1, value_from_double (type=0x852c388, num=17.93) at [...]/gdb/value.c:3164
3164 struct value *val = allocate_value (type);
(gdb) print *type
$2 = {pointer_type = 0x0, reference_type = 0x0, chain = 0x852c388, instance_flags = 0, length = 4, main_type = 0x852c3c0}
(gdb) print *type->main_type
$3 = {code = TYPE_CODE_FLT, flag_unsigned = 0, flag_nosign = 0, flag_stub = 0, flag_target_stub = 0, flag_static = 0, flag_prototyped = 0, flag_incomplete = 0, flag_varargs = 0, flag_vector = 0, flag_stub_supported = 0,
flag_gnu_ifunc = 0, flag_fixed_instance = 0, flag_objfile_owned = 0, flag_declared_class = 0, flag_flag_enum = 0, type_specific_field = TYPE_SPECIFIC_NONE, nfields = 0, vptr_fieldno = -1, name = 0x852c408 "double", tag_name = 0x0,
owner = {objfile = 0x8512f80, gdbarch = 0x8512f80}, target_type = 0x0, flds_bnds = {fields = 0x0, bounds = 0x0}, vptr_basetype = 0x0, type_specific = {cplus_stuff = 0x8476d8c, gnat_stuff = 0x8476d8c, floatformat = 0x8476d8c,
func_stuff = 0x8476d8c}}
(gdb) print type->main_type->type_specific->floatformat[1]
$36 = (const struct floatformat *) 0x8461f40
(gdb) print host_float_format
$31 = (const struct floatformat *) 0x8461e80
(gdb) print host_double_format
$35 = (const struct floatformat *) 0x8461f40
Here we can already see that, TYPE's floatformat is host_double_format,
which is 64-bit double format. However, in my understanding, TYPE is
meant to be a 32-bit double type, having a 32-bit double format.
Stepping further, allocate_value, allocate_value_contents:
allocate_value (type=0x852c388) at [...]/gdb/value.c:705
705 allocate_value_contents (val);
(gdb)
allocate_value_contents (val=0x8522508) at [...]/gdb/value.c:694
694 if (!val->contents)
(gdb)
695 val->contents = (gdb_byte *) xzalloc (TYPE_LENGTH (val->enclosing_type));
(gdb)
xzalloc (size=4) at [...]/gdb/common/common-utils.c:100
100 return xcalloc (1, size);
So indeed we allocate 32 bits.
Back in value_from_double, on to doublest.c:store_typed_floating:
void
store_typed_floating (void *addr, const struct type *type, DOUBLEST val)
{
const struct floatformat *fmt = floatformat_from_type (type);
[...]
floatformat_from_doublest (fmt, &val, addr);
}
store_typed_floating (addr=0x850a570, type=0x852c388, val=17.93) at [...]/gdb/doublest.c:859
859 const struct floatformat *fmt = floatformat_from_type (type);
[...]
881 floatformat_from_doublest (fmt, &val, addr);
(gdb) s
floatformat_from_doublest (fmt=0x8461f40, in=0xffffbfd8, out=0x850a570) at [...]/gdb/doublest.c:757
Here we indeed see floatformat fmt 0x8461f40 being passed, which is
host_double_format, the 64-bit double format (see Bearkpoint 1 above).
In the following, things break:
(gdb) s
758 if (fmt == host_float_format)
(gdb)
764 else if (fmt == host_double_format)
(gdb)
766 double val = *in;
(gdb)
768 memcpy (out, &val, sizeof (val));
We have host_double_format, »sizeof val« is 64 bits, but we only
allocated 32 bits, thus memcpy corrupts the memory.
Looking at doublest:floatformat_from_type:
const struct floatformat *
floatformat_from_type (const struct type *type)
{
struct gdbarch *gdbarch = get_type_arch (type);
gdb_assert (TYPE_CODE (type) == TYPE_CODE_FLT);
if (TYPE_FLOATFORMAT (type) != NULL)
return TYPE_FLOATFORMAT (type)[gdbarch_byte_order (gdbarch)];
else
return floatformat_from_length (gdbarch, TYPE_LENGTH (type));
}
In our case, »TYPE_FLOATFORMAT (type)[gdbarch_byte_order (gdbarch)]« is
host_double_format (see Breakpoint 1 above). If I instead make that take
the floatformat_from_length route, it correctly returns the 32-bit
host_float_type, and everything works as expected.
So, my understanding is that »TYPE_FLOATFORMAT (type)« is set
incorrectly -- but where and why is this happening?
Grüße,
Thomas
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 489 bytes
Desc: not available
URL: <http://sourceware.org/pipermail/gdb/attachments/20120809/6a5ef2ca/attachment.sig>
More information about the Gdb
mailing list