Binutils with MCST patches
d7a87b5e43
Running the testsuite with a gdb configured with --enable-libmcheck reveals a problem: (gdb) ptype 3 * 2.0 type = <12-byte float> memory clobbered past end of allocated block ERROR: Process no longer exists UNRESOLVED: gdb.ada/ptype_arith_binop.exp: ptype 3 * 2.0 (gdb) PASS: gdb.dlang/expression.exp: ptype 0x1.FFFFFFFFFFFFFp1023 ptype 0x1p-52L type = real memory clobbered past end of allocated block ERROR: Process no longer exists UNRESOLVED: gdb.dlang/expression.exp: ptype 0x1p-52L Even though this shows up with Ada and D, it's easy to reproduce in C too. We just need to print a long double, when the current arch is 32-bit, which is the default when gdb starts up: $ ./gdb -q -ex "ptype 1.0L" type = long double memory clobbered past end of allocated block Aborted (core dumped) Valgrind shows: ==22159== Invalid write of size 8 ==22159== at 0x8464A9: floatformat_from_doublest (doublest.c:756) ==22159== by 0x846822: store_typed_floating (doublest.c:867) ==22159== by 0x6A7959: value_from_double (value.c:3662) ==22159== by 0x6A9F2D: evaluate_subexp_standard (eval.c:745) ==22159== by 0x7F31AF: evaluate_subexp_c (c-lang.c:716) ==22159== by 0x6A8986: evaluate_subexp (eval.c:79) ==22159== by 0x6A8BA3: evaluate_type (eval.c:174) ==22159== by 0x817CCF: whatis_exp (typeprint.c:456) ==22159== by 0x817EAA: ptype_command (typeprint.c:508) ==22159== by 0x5F267B: do_cfunc (cli-decode.c:105) ==22159== by 0x5F5618: cmd_func (cli-decode.c:1885) ==22159== by 0x83622A: execute_command (top.c:475) ==22159== Address 0x8c6cb28 is 8 bytes inside a block of size 12 alloc'd ==22159== at 0x4C2AA98: calloc (vg_replace_malloc.c:711) ==22159== by 0x87384A: xcalloc (common-utils.c:83) ==22159== by 0x873889: xzalloc (common-utils.c:93) ==22159== by 0x6A34CB: allocate_value_contents (value.c:1036) ==22159== by 0x6A3501: allocate_value (value.c:1047) ==22159== by 0x6A790A: value_from_double (value.c:3656) ==22159== by 0x6A9F2D: evaluate_subexp_standard (eval.c:745) ==22159== by 0x7F31AF: evaluate_subexp_c (c-lang.c:716) ==22159== by 0x6A8986: evaluate_subexp (eval.c:79) ==22159== by 0x6A8BA3: evaluate_type (eval.c:174) ==22159== by 0x817CCF: whatis_exp (typeprint.c:456) ==22159== by 0x817EAA: ptype_command (typeprint.c:508) ==22159== type = long double (gdb) Even if the target and host floating-point formats match, the length of the types might still be different. On x86, long double is the 80-bit extended precision type on both 32-bit and 64-bit ABIs, but by default it is stored as 12 bytes on 32-bit, and 16 bytes on 64-bit, for alignment reasons. Several places in doublest.c already consider this, but floatformat_to_doublest and floatformat_from_doublest miss it. E.g., convert_typed_floating and store_typed_floating, Tested on x86-64 Fedora 23 with --enable-libmcheck, where it fixes the crashed above. gdb/ChangeLog: 2016-03-09 Pedro Alves <palves@redhat.com> * doublest.c: Extend comments. (floatformat_to_doublest, floatformat_from_doublest): Copy the floatformat's total size, not the host type's size. |
||
---|---|---|
bfd | ||
binutils | ||
config | ||
cpu | ||
elfcpp | ||
etc | ||
gas | ||
gdb | ||
gold | ||
gprof | ||
include | ||
intl | ||
ld | ||
libdecnumber | ||
libiberty | ||
opcodes | ||
readline | ||
sim | ||
texinfo | ||
zlib | ||
.cvsignore | ||
.gitattributes | ||
.gitignore | ||
ChangeLog | ||
compile | ||
config-ml.in | ||
config.guess | ||
config.rpath | ||
config.sub | ||
configure | ||
configure.ac | ||
COPYING | ||
COPYING3 | ||
COPYING3.LIB | ||
COPYING.LIB | ||
COPYING.LIBGLOSS | ||
COPYING.NEWLIB | ||
depcomp | ||
djunpack.bat | ||
install-sh | ||
libtool.m4 | ||
lt~obsolete.m4 | ||
ltgcc.m4 | ||
ltmain.sh | ||
ltoptions.m4 | ||
ltsugar.m4 | ||
ltversion.m4 | ||
MAINTAINERS | ||
Makefile.def | ||
Makefile.in | ||
Makefile.tpl | ||
makefile.vms | ||
missing | ||
mkdep | ||
mkinstalldirs | ||
move-if-change | ||
README | ||
README-maintainer-mode | ||
setup.com | ||
src-release.sh | ||
symlink-tree | ||
ylwrap |
README for GNU development tools This directory contains various GNU compilers, assemblers, linkers, debuggers, etc., plus their support routines, definitions, and documentation. If you are receiving this as part of a GDB release, see the file gdb/README. If with a binutils release, see binutils/README; if with a libg++ release, see libg++/README, etc. That'll give you info about this package -- supported targets, how to use it, how to report bugs, etc. It is now possible to automatically configure and build a variety of tools with one command. To build all of the tools contained herein, run the ``configure'' script here, e.g.: ./configure make To install them (by default in /usr/local/bin, /usr/local/lib, etc), then do: make install (If the configure script can't determine your type of computer, give it the name as an argument, for instance ``./configure sun4''. You can use the script ``config.sub'' to test whether a name is recognized; if it is, config.sub translates it to a triplet specifying CPU, vendor, and OS.) If you have more than one compiler on your system, it is often best to explicitly set CC in the environment before running configure, and to also set CC when running make. For example (assuming sh/bash/ksh): CC=gcc ./configure make A similar example using csh: setenv CC gcc ./configure make Much of the code and documentation enclosed is copyright by the Free Software Foundation, Inc. See the file COPYING or COPYING.LIB in the various directories, for a description of the GNU General Public License terms under which you can copy the files. REPORTING BUGS: Again, see gdb/README, binutils/README, etc., for info on where and how to report problems.