Binutils with MCST patches
706d088346
Ports for Hardvard architectures will typically have in their
pointer_to_address hook a check for TYPE_CODE_SPACE in their
"pointer_to_address" gdbarch method. E.g., rl78's:
/* Is it a code address? */
if (TYPE_CODE (TYPE_TARGET_TYPE (type)) == TYPE_CODE_FUNC
|| TYPE_CODE (TYPE_TARGET_TYPE (type)) == TYPE_CODE_METHOD
|| TYPE_CODE_SPACE (TYPE_TARGET_TYPE (type))
|| TYPE_LENGTH (type) == 4)
return rl78_make_instruction_address (addr);
else
return rl78_make_data_address (addr);
The avr port is similar.
The vtable type is a struct type gdb itself bakes. Being neither a
function, nor a method, and absent explicit flagging as residing in
code space, ends up being considered data.
This patch marks the type as code when it is created, on the theory
that this is needed for all Hardvard architectures. I believe this
should make no difference on archs with flat address space. Testing
on x86-64 GNU/Linux shows no changes.
gdb/
2014-02-12 Pedro Alves <palves@redhat.com>
Kevin Buettner <kevinb@redhat.com>
* gnu-v3-abi.c (build_gdb_vtable_type): Return a type marked with
TYPE_INSTANCE_FLAG_CODE_SPACE.
Kevin Buettner, at
<https://sourceware.org/ml/gdb-patches/2014-02/msg00338.html>, writes,
re. rl78:
This patch, for rl78 using the default multilib, fixes 5 failures in
gdb.cp/casts.exp, 2 failures in gdb.cp/class2.exp, 115 failures in
gdb.mi/mi-var-rtti.exp, and 2 failures in gdb.python/py-value.exp.
It introduces 9 failures (regressions) in gdb.mi/mi-var-rtti.exp.
One of the regressions is:
FAIL: gdb.mi/mi-var-rtti.exp: list children of s.public in type_update_when_use_rtti
The relevant lines from the log file from a pre-patch test run are as
follows:
-var-list-children S.public
^done,numchild="1",children=[child={name="S.public.ptr",exp="ptr",numchild="1",type="Base *",thread-id="1"}],has_more="0"
(gdb)
PASS: gdb.mi/mi-var-rtti.exp: list children of s.public in type_update_when_use_rtti
Expecting: \^done,numchild=".*",children=\[child={name="S.public.ptr.public",exp="public",numchild="1"(,thread-id="[0-9]+")?}.*\],has_more="0"
Expecting: ^(-var-list-children S\.public\.ptr [
]+)?(\^done,numchild=".*",children=\[child={name="S.public.ptr.public",exp="public",numchild="1"(,thread-id="[0-9]+")?}.*\],has_more="0"[
]+[(]gdb[)]
[ ]*)
The same set of lines for the failing (post-patch) run are instead:
-var-list-children S.public
&"warning: can't find linker symbol for virtual table for `Base' value\n"
&"warning: found `typeinfo for __cxxabiv1::__vmi_class_type_info' instead\n"
&"warning: can't find linker symbol for virtual table for `Base' value\n"
&"warning: found `typeinfo for __cxxabiv1::__vmi_class_type_info' instead\n"
&"warning: can't find linker symbol for virtual table for `Base' value\n"
&"warning: found `typeinfo for __cxxabiv1::__vmi_class_type_info' instead\n"
^done,numchild="1",children=[child={name="S.public.ptr",exp="ptr",numchild="1",type="Base *",thread-id="1"}],has_more="0"
(gdb)
FAIL: gdb.mi/mi-var-rtti.exp: list children of s.public in type_update_when_use_rtti
Expecting: \^done,numchild=".*",children=\[child={name="S.public.ptr.public",exp="public",numchild="1"(,thread-id="[0-9]+")?}.*\],has_more="0"
Expecting: ^(-var-list-children S\.public\.ptr [
]+)?(\^done,numchild=".*",children=\[child={name="S.public.ptr.public",exp="public",numchild="1"(,thread-id="[0-9]+")?}.*\],has_more="0"[
]+[(]gdb[)]
[ ]*)
Note that the difference between these are the warnings regarding
linker symbols. Aside from the warnings, the result is the same.
I.e. gdb produces the correct answer despite the warnings. The
reason for the other 8 failures is the same: the test harness is not
expecting these warnings.
I spent some time (a while ago) looking at the reason for these
warnings. As I recall, we are now getting further along in the type
resolution process than we were without my patch. I.e. for the
example above, the code in question never got to the point where it
was looking for the specified linker symbol. So it seems to me that,
at worst, my patch exposes some other problem, but is not directly the
cause of the problem.
|
||
|---|---|---|
| bfd | ||
| binutils | ||
| config | ||
| cpu | ||
| elfcpp | ||
| etc | ||
| gas | ||
| gdb | ||
| gold | ||
| gprof | ||
| include | ||
| intl | ||
| ld | ||
| libdecnumber | ||
| libiberty | ||
| opcodes | ||
| readline | ||
| sim | ||
| texinfo | ||
| .cvsignore | ||
| .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 | ||
| 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.