Re: [PATCHv5 2/3] gdb/regformats: add osabi information to generated .dat files

[Kevin Buettner <kevinb@redhat.com>]

On Sun, 27 Oct 2024 20:07:41 +0000
Andrew Burgess <aburgess@redhat.com> wrote:

> 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.

Thanks for the detail explanation!

Based on your problem description, etc, these changes make sense to
me.  Also, as there should be no user visible changes, I think this is
good to go in.

Approved-by: Kevin Buettner <kevinb@redhat.com>