mirror of
https://sourceware.org/git/binutils-gdb.git
synced 2024-11-21 01:12:32 +08:00
06e9986d02
Some gdbserver targets generate their target description based on the gdb/regformats/*.dat files. These .dat files are generated from a matching xml file in gdb/features/. Lets consider a concrete example: Take gdb/features/or1k-linux.xml, this file is processed by gdb/features/Makefile to create gdb/regformats/or1k-linux.dat. When gdbserver is built for the or1k target the file or1k-linux-generated.cc is generated using the gdb/regformats/regdat.sh script. This .cc file is then compiled and linked into gdbserver. The or1k-linux-generated.cc file contains the function init_registers_or1k_linux which is called from within gdbserver, this function creates a target_desc object and sets its xmltarget field to a fixed string. This fixed string is the xml filename that was originally used to generate the xml file, in this case or1k-linux.xml. Additionally, as part of the gdbserver build the file or1k-linux.xml is converted to a string and placed in the file xml-builtin-generated.cc which is then built into gdbserver. Now when GDB asks gdbserver for the target description, gdbserver returns the fixed xmltarget string, which is the name of an xml file. GDB will then ask gdbserver for that file and gdbserver will return the contents of that file thanks to the xml-builtin-generated.cc file's contents. This is all rather complicated, but it does work. So what's the problem that I'm fixing? Well or1k-linux.xml does contain the osabi information, so this will be returned from gdbserver to GDB. That's good. However, the target_desc object created in init_registers_or1k_linux will not have its osabi set correctly. Now this doesn't really matter too much except init_registers_or1k_linux includes a call to init_target_desc. In the next commit I want to extend init_target_desc to require an osabi to be passed in. The motivation for this will be explained in the next commit, but if we accept for a moment that this is something that should be done, then the question is what osabi should we use in init_registers_or1k_linux? Ideally we'd use the osabi which is set in or1k-linux.xml. If we do that then everything will remain consistent, which is a good thing. And so, to get the osabi from or1k-linux.xml into init_registers_or1k_linux, we first need to get the osabi information into or1k-linux.dat file, and this is what this commit does. I've added a new xsl script print-osabi.xsl and updated gdb/features/Makefile to make use of this script. Then I regenerated all of the .dat files. Now every .dat file contains either: osabi:GNU/Linux osabi:unknown The first is for xml files containing <osabi>GNU/Linux</osabi> and the second is for xml files that don't contain an osabi element. This commit doesn't attempt to make use of the osabi information in the .dat files, that will come in the next commit. There should be no user visible changes after this commit. Approved-By: Kevin Buettner <kevinb@redhat.com> |
||
|---|---|---|
| bfd | ||
| binutils | ||
| config | ||
| contrib | ||
| cpu | ||
| elfcpp | ||
| etc | ||
| gas | ||
| gdb | ||
| gdbserver | ||
| gdbsupport | ||
| gnulib | ||
| gold | ||
| gprof | ||
| gprofng | ||
| include | ||
| ld | ||
| libbacktrace | ||
| libctf | ||
| libdecnumber | ||
| libiberty | ||
| libsframe | ||
| opcodes | ||
| readline | ||
| sim | ||
| texinfo | ||
| zlib | ||
| .cvsignore | ||
| .editorconfig | ||
| .gitattributes | ||
| .gitignore | ||
| .pre-commit-config.yaml | ||
| 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 | ||
| SECURITY.txt | ||
| 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.