mirror of
https://sourceware.org/git/binutils-gdb.git
synced 2025-04-12 14:33:06 +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>
135 lines
1.2 KiB
Plaintext
135 lines
1.2 KiB
Plaintext
# THIS FILE IS GENERATED. -*- buffer-read-only: t -*- vi :set ro:
|
|
# Generated from: s390-gs-linux64.xml
|
|
name:s390_gs_linux64
|
|
xmltarget:s390-gs-linux64.xml
|
|
expedite:r14,r15,pswa
|
|
osabi:GNU/Linux
|
|
32:pswm
|
|
32:pswa
|
|
32:r0h
|
|
32:r0l
|
|
32:r1h
|
|
32:r1l
|
|
32:r2h
|
|
32:r2l
|
|
32:r3h
|
|
32:r3l
|
|
32:r4h
|
|
32:r4l
|
|
32:r5h
|
|
32:r5l
|
|
32:r6h
|
|
32:r6l
|
|
32:r7h
|
|
32:r7l
|
|
32:r8h
|
|
32:r8l
|
|
32:r9h
|
|
32:r9l
|
|
32:r10h
|
|
32:r10l
|
|
32:r11h
|
|
32:r11l
|
|
32:r12h
|
|
32:r12l
|
|
32:r13h
|
|
32:r13l
|
|
32:r14h
|
|
32:r14l
|
|
32:r15h
|
|
32:r15l
|
|
32:acr0
|
|
32:acr1
|
|
32:acr2
|
|
32:acr3
|
|
32:acr4
|
|
32:acr5
|
|
32:acr6
|
|
32:acr7
|
|
32:acr8
|
|
32:acr9
|
|
32:acr10
|
|
32:acr11
|
|
32:acr12
|
|
32:acr13
|
|
32:acr14
|
|
32:acr15
|
|
32:fpc
|
|
64:f0
|
|
64:f1
|
|
64:f2
|
|
64:f3
|
|
64:f4
|
|
64:f5
|
|
64:f6
|
|
64:f7
|
|
64:f8
|
|
64:f9
|
|
64:f10
|
|
64:f11
|
|
64:f12
|
|
64:f13
|
|
64:f14
|
|
64:f15
|
|
32:orig_r2
|
|
32:last_break
|
|
32:system_call
|
|
64:tdb0
|
|
64:tac
|
|
64:tct
|
|
64:atia
|
|
64:tr0
|
|
64:tr1
|
|
64:tr2
|
|
64:tr3
|
|
64:tr4
|
|
64:tr5
|
|
64:tr6
|
|
64:tr7
|
|
64:tr8
|
|
64:tr9
|
|
64:tr10
|
|
64:tr11
|
|
64:tr12
|
|
64:tr13
|
|
64:tr14
|
|
64:tr15
|
|
64:v0l
|
|
64:v1l
|
|
64:v2l
|
|
64:v3l
|
|
64:v4l
|
|
64:v5l
|
|
64:v6l
|
|
64:v7l
|
|
64:v8l
|
|
64:v9l
|
|
64:v10l
|
|
64:v11l
|
|
64:v12l
|
|
64:v13l
|
|
64:v14l
|
|
64:v15l
|
|
128:v16
|
|
128:v17
|
|
128:v18
|
|
128:v19
|
|
128:v20
|
|
128:v21
|
|
128:v22
|
|
128:v23
|
|
128:v24
|
|
128:v25
|
|
128:v26
|
|
128:v27
|
|
128:v28
|
|
128:v29
|
|
128:v30
|
|
128:v31
|
|
64:gsd
|
|
64:gssm
|
|
64:gsepla
|
|
64:bc_gsd
|
|
64:bc_gssm
|
|
64:bc_gsepla
|