mirror of
https://sourceware.org/git/binutils-gdb.git
synced 2025-01-30 12:44:10 +08:00
caa7fd04f6
This commit adds a new maintenance command that dumps the current target description as an XML document. This is a maintenance command as I currently only see this being useful for GDB developers, or for people debugging a new remote target. By default the command will print whatever the current target description is, whether this was delivered by the remote, loaded by the user from a file, or if it is a built in target within GDB. The command can also take an optional filename argument. In this case GDB loads a target description from the file, and then reprints it. This could be useful for testing GDB's parsing of target descriptions, or to check that GDB can successfully parse a particular XML description. It is worth noting that the XML description printed will not be an exact copy of the document fed into GDB. For example this minimal input file: <target> <feature name="abc"> <reg name="r1" bitsize="32"/> </feature> </target> Will produce this output: (gdb) maint print xml-tdesc path/to/file.xml <?xml version="1.0"?> <!DOCTYPE target SYSTEM "gdb-target.dtd"> <target> <feature name="abc"> <reg name="r1" bitsize="32" type="int" regnum="0"/> </feature> </target> Notice that GDB filled in both the 'type' and 'regnum' fields of the <reg>. I think this is actually a positive as it means we get to really understand how GDB processed the document, if GDB made some assumptions that differ to those the user expected then hopefully this will bring those issues to the users attention. To implement this I have tweaked the output produced by the print_xml_feature which is defined within the gdbsupport/ directory. The changes I have made to this class are: 1. The <architecture>...</architecture> tags are now not produced if the architecture name is NULL. 2. The <osabi>...</osabi> tags get a newline at the end. 3. And, the whole XML document is indented using white space in a nested fashion (as in the example output above). I think that these changes should be fine, the print_xml_feature class is used: 1. In gdbserver to generate an XML document to send as the target description to GDB. 2. In GDB as part of a self-check function, a target_desc is converted to XML then parsed back into a target_desc. We then check the before and after target_desc objects are the same. 3. In the new 'maint print xml-tdesc' command. In all of these use cases adding the extra white space should be fine. gdbsupport/ChangeLog: * tdesc.cc (print_xml_feature::visit_pre): Use add_line to add output content, and call indent as needed in all overloaded variants. (print_xml_feature::visit_post): Likewise. (print_xml_feature::visit): Likewise. (print_xml_feature::add_line): Two new overloaded functions. * tdesc.h (print_xml_feature::indent): New member function. (print_xml_feature::add_line): Two new overloaded member functions. (print_xml_feature::m_depth): New member variable. gdb/ChangeLog: * target-descriptions.c (tdesc_architecture_name): Protect against NULL pointer dereference. (maint_print_xml_tdesc_cmd): New function. (_initialize_target_descriptions): Register new 'maint print xml-tdesc' command and give it the filename completer. * NEWS: Mention new 'maint print xml-tdesc' command. gdb/testsuite/ChangeLog: * gdb.xml/tdesc-reload.c: New file. * gdb.xml/tdesc-reload.exp: New file. * gdb.xml/maint-xml-dump-01.xml: New file. * gdb.xml/maint-xml-dump-02.xml: New file. * gdb.xml/maint-xml-dump.exp: New file. gdb/doc/ChangeLog: * gdb.texinfo (Maintenance Commands): Document new 'maint print xml-desc' command. |
||
---|---|---|
bfd | ||
binutils | ||
config | ||
contrib | ||
cpu | ||
elfcpp | ||
etc | ||
gas | ||
gdb | ||
gdbserver | ||
gdbsupport | ||
gnulib | ||
gold | ||
gprof | ||
include | ||
intl | ||
ld | ||
libctf | ||
libdecnumber | ||
libiberty | ||
opcodes | ||
readline | ||
sim | ||
texinfo | ||
zlib | ||
.cvsignore | ||
.gitattributes | ||
.gitignore | ||
ar-lib | ||
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 | ||
multilib.am | ||
README | ||
README-maintainer-mode | ||
setup.com | ||
src-release.sh | ||
symlink-tree | ||
test-driver | ||
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.