diff options
| author | Andrew Burgess <aburgess@redhat.com> | 2024-10-11 21:28:47 +0100 |
|---|---|---|
| committer | Andrew Burgess <aburgess@redhat.com> | 2024-11-12 12:51:36 +0000 |
| commit | 06e9986d025d8c8e5ae8dda3ef0feeb8c24104a6 (patch) | |
| tree | 92734ea93e67ea176f5e3cb086bf4cf1942d0ade /gdb/regformats/s390x-linux64.dat | |
| parent | 9b5ba7e49edcb75ca48908d6cd64db01a6e900cf (diff) | |
| download | gdb-06e9986d025d8c8e5ae8dda3ef0feeb8c24104a6.zip gdb-06e9986d025d8c8e5ae8dda3ef0feeb8c24104a6.tar.gz gdb-06e9986d025d8c8e5ae8dda3ef0feeb8c24104a6.tar.bz2 | |
gdb/regformats: add osabi information to generated .dat files
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>
Diffstat (limited to 'gdb/regformats/s390x-linux64.dat')
| -rw-r--r-- | gdb/regformats/s390x-linux64.dat | 1 |
1 files changed, 1 insertions, 0 deletions
diff --git a/gdb/regformats/s390x-linux64.dat b/gdb/regformats/s390x-linux64.dat index 5832c43..a393b58 100644 --- a/gdb/regformats/s390x-linux64.dat +++ b/gdb/regformats/s390x-linux64.dat @@ -3,6 +3,7 @@ name:s390x_linux64 xmltarget:s390x-linux64.xml expedite:r14,r15,pswa +osabi:GNU/Linux 64:pswm 64:pswa 64:r0 |