0f59d5fc1c
GCC PR83906 [1] is about a GCC/libstdc++ GDB/Python type printer
testcase failing randomly, as shown by running (in libstdc++'s
testsuite):
make check RUNTESTFLAGS=prettyprinters.exp=80276.cc
in a loop. Sometimes you get this:
FAIL: libstdc++-prettyprinters/80276.cc whatis p4
I.e., this:
type = std::unique_ptr<std::vector<std::unique_ptr<std::list<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >>[]>>[99]>
instead of this:
type = std::unique_ptr<std::vector<std::unique_ptr<std::list<std::string>[]>>[99]>
Jonathan Wakely tracked it on the printer side to this bit in
libstdc++'s type printer:
if self.type_obj == type_obj:
return strip_inline_namespaces(self.name)
This assumes the two types resolve to the same gdb.Type but some times
the comparison unexpectedly fails.
Running the testcase manually under Valgrind finds the problem in GDB:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
==6118== Conditional jump or move depends on uninitialised value(s)
==6118== at 0x4C35CB0: bcmp (vg_replace_strmem.c:1100)
==6118== by 0x6F773A: check_types_equal(type*, type*, VEC_type_equality_entry_d**) (gdbtypes.c:3515)
==6118== by 0x6F7B00: check_types_worklist(VEC_type_equality_entry_d**, bcache*) (gdbtypes.c:3618)
==6118== by 0x6F7C03: types_deeply_equal(type*, type*) (gdbtypes.c:3655)
==6118== by 0x4D5B06: typy_richcompare(_object*, _object*, int) (py-type.c:1007)
==6118== by 0x63D7E6C: PyObject_RichCompare (object.c:961)
==6118== by 0x646EAEC: PyEval_EvalFrameEx (ceval.c:4960)
==6118== by 0x646DC08: PyEval_EvalFrameEx (ceval.c:4519)
==6118== by 0x646DC08: PyEval_EvalFrameEx (ceval.c:4519)
==6118== by 0x646DC08: PyEval_EvalFrameEx (ceval.c:4519)
==6118== by 0x646DC08: PyEval_EvalFrameEx (ceval.c:4519)
==6118== by 0x646DC08: PyEval_EvalFrameEx (ceval.c:4519)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
That "bcmp" call is really a memcmp call in check_types_equal. The
problem is that gdb is memcmp'ing two objects that are equal in value:
(top-gdb) p *TYPE_RANGE_DATA (type1)
$1 = {low = {kind = PROP_CONST, data = {const_val = 0, baton = 0x0}}, high = {kind = PROP_CONST, data = {const_val = 15, baton = 0xf}}, flag_upper_bound_is_count = 0,
flag_bound_evaluated = 0}
(top-gdb) p *TYPE_RANGE_DATA (type2)
$2 = {low = {kind = PROP_CONST, data = {const_val = 0, baton = 0x0}}, high = {kind = PROP_CONST, data = {const_val = 15, baton = 0xf}}, flag_upper_bound_is_count = 0,
flag_bound_evaluated = 0}
but differ in padding. Notice the 4-byte hole:
(top-gdb) ptype /o range_bounds
/* offset | size */ type = struct range_bounds {
/* 0 | 16 */ struct dynamic_prop {
/* 0 | 4 */ dynamic_prop_kind kind;
/* XXX 4-byte hole */
/* 8 | 8 */ union dynamic_prop_data {
/* 8 */ LONGEST const_val;
/* 8 */ void *baton;
/* total size (bytes): 8 */
} data;
which is filled with garbage:
(top-gdb) x /40bx TYPE_RANGE_DATA (type1)
0x2fa7ea0: 0x01 0x00 0x00 0x00 0x43 0x01 0x00 0x00
^^^^^^^^^^^^^^^^^^^^^^^^^^^^
0x2fa7ea8: 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x2fa7eb0: 0x01 0x00 0x00 0x00 0xfe 0x7f 0x00 0x00
0x2fa7eb8: 0x0f 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x2fa7ec0: 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
(top-gdb) x /40bx TYPE_RANGE_DATA (type2)
0x20379b0: 0x01 0x00 0x00 0x00 0xfe 0x7f 0x00 0x00
^^^^^^^^^^^^^^^^^^^^^^^^^^^^
0x20379b8: 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x20379c0: 0x01 0x00 0x00 0x00 0xfe 0x7f 0x00 0x00
0x20379c8: 0x0f 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x20379d0: 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
(top-gdb) p memcmp (TYPE_RANGE_DATA (type1), TYPE_RANGE_DATA (type2), sizeof (*TYPE_RANGE_DATA (type1)))
$3 = -187
In some cases objects of type range_bounds are memset when allocated,
but then their dynamic_prop low/high fields are copied over from some
template dynamic_prop object that wasn't memset. E.g.,
create_static_range_type's low/high locals are left with garbage in
the padding, and then that padding is copied over to the range_bounds
object's low/high fields.
At first, I considered making sure to always memset range_bounds
objects, thinking that maybe type objects are being put in some bcache
instance somewhere. But then I hacked bcache/bcache_full to poison
non-pod types, and made dynamic_prop a non-pod, and GDB still
compiled.
So given that, it seems safest to not assume padding will always be
memset, and instead treat them as regular value types, implementing
(in)equality operators and using those instead of memcmp.
This fixes the random FAILs in GCC's testcase.
[1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83906
gdb/ChangeLog:
2018-01-24 Pedro Alves <palves@redhat.com>
GCC PR libstdc++/83906
* gdbtypes.c (operator==(const dynamic_prop &,
const dynamic_prop &)): New.
(operator==(const range_bounds &, const range_bounds &)): New.
(check_types_equal): Use them instead of memcmp.
* gdbtypes.h (operator==(const dynamic_prop &,
const dynamic_prop &)): Declare.
(operator!=(const dynamic_prop &, const dynamic_prop &)): Declare.
(operator==(const range_bounds &, const range_bounds &)): Declare.
(operator!=(const range_bounds &, const range_bounds &)): Declare.
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.