Re: [PATCH v2 0/8] Remove XML files from gdbserver

[Pedro Alves <palves@redhat.com>]

On 01/24/2018 09:26 AM, Alan Hayward wrote:
> In exisiting code, gdbserver uses C code auto generated from xml files to
> create target descriptions. When sending an xml description to GDB, it
> creates an xml containing just the name of the original xml file.
> Upon receipt, GDB reads and parses a local copy of xml file.

Huh?  What do you mean reads and parses a _local copy_?
That's false AFAICS.

GDB fetches named file from the server, not from the local filesystem.
E.g., on x86-64:

Sending packet: $qXfer:features:read:target.xml:0,fff#7d...Packet received: l<?xml version="1.0"?><!DOCTYPE target SYSTEM "gdb-target.dtd"><target><architecture>i386:x86-64</architecture><osabi>GNU/Linux</osabi><xi:include href="64bit-core.xml"/><xi:include href="64bit-sse.xml"/><xi:include href="64bit-linux.xml"/><xi:include href="64bit-segments.xml"/><xi:include href="64bit-avx.xml"/></target>
Sending packet: $qXfer:features:read:64bit-core.xml:0,fff#75...Packet received: l<?xml version="1.0"?>\n<!-- Copyright (C) 2010-2018 Free Software Foundation, Inc.\n\n     Copying and distribution of this file, with or without modification,\n     are permitted in any medium without royalty provided the copyright\n     notice and this notice are preserved.  -->\n\n<!DOCTYPE feature SYSTEM "gdb-target.dtd">\n<feature name="org.gnu.gdb.i386.core">\n  <flags id="i386_eflags" size="4">\n    <field name="CF" start="0" end="0"/>\n    <field name="" start="1" end="1"/>\n    <field name="PF" start="2" end=[12 bytes omitted]
Sending packet: $qXfer:features:read:64bit-sse.xml:0,fff#17...Packet received: l<?xml version="1.0"?>\n<!-- Copyright (C) 2010-2018 Free Software Foundation, Inc.\n\n     Copying and distribution of this file, with or without modification,\n     are permitted in any medium without royalty provided the copyright\n     notice and this notice are preserved.  -->\n\n<!DOCTYPE feature SYSTEM "gdb-target.dtd">\n<feature name="org.gnu.gdb.i386.sse">\n  <vector id="v4f" type="ieee_single" count="4"/>\n  <vector id="v2d" type="ieee_double" count="2"/>\n  <vector id="v16i8" type="int8" count="16"/>\n  <vec[12 bytes omitted]
Sending packet: $qXfer:features:read:64bit-linux.xml:0,fff#fc...Packet received: l<?xml version="1.0"?>\n<!-- Copyright (C) 2010-2018 Free Software Foundation, Inc.\n\n     Copying and distribution of this file, with or without modification,\n     are permitted in any medium without royalty provided the copyright\n     notice and this notice are preserved.  -->\n\n<!DOCTYPE feature SYSTEM "gdb-target.dtd">\n<feature name="org.gnu.gdb.i386.linux">\n  <reg name="orig_rax" bitsize="64" type="int" regnum="57"/>\n</feature>\n
Sending packet: $qXfer:features:read:64bit-segments.xml:0,fff#32...Packet received: l<?xml version="1.0"?>\n<!-- Copyright (C) 2016-2018 Free Software Foundation, Inc.\n\n     Copying and distribution of this file, with or without modification,\n     are permitted in any medium without royalty provided the copyright\n     notice and this notice are preserved.  -->\n\n<!DOCTYPE feature SYSTEM "gdb-target.dtd">\n<feature name="org.gnu.gdb.i386.segments">\n  <reg name="fs_base" bitsize="64" type="int"/>\n  <reg name="gs_base" bitsize="64" type="int"/>\n</feature>\n
Sending packet: $qXfer:features:read:64bit-avx.xml:0,fff#1b...Packet received: l<?xml version="1.0"?>\n<!-- Copyright (C) 2010-2018 Free Software Foundation, Inc.\n\n     Copying and distribution of this file, with or without modification,\n     are permitted in any medium without royalty provided the copyright\n     notice and this notice are preserved.  -->\n\n<!DOCTYPE feature SYSTEM "gdb-target.dtd">\n<feature name="org.gnu.gdb.i386.avx">\n  <reg name="ymm0h" bitsize="128" type="uint128"/>\n  <reg name="ymm1h" bitsize="128" type="uint128"/>\n  <reg name="ymm2h" bitsize="128" type="uint128"/>[11 bytes omitted]


Above we see GDB processing the xi:includes by subsequently fetching the
xi:included files from the server.

There is already some support in gdbserver for baking in the XML
code directly in gdbserver instead of reading it from (gdbserver's)
filesystem:

  /* `desc->xmltarget' defines what to return when looking for the
     "target.xml" file.  Its contents can either be verbatim XML code
     (prefixed with a '@') or else the name of the actual XML file to
     be used in place of "target.xml".

     This variable is set up from the auto-generated
     init_registers_... routine for the current target.  */

  if (strcmp (annex, "target.xml") == 0)
    {
      const char *ret = tdesc_get_features_xml ((target_desc*) desc);

      if (*ret == '@')
	return ret + 1;
      else
	annex = ret;
    }

Can you please clarify the rationale for the series?

The current justification doesn't look very convincing to me.  This
is going to be probably something around dynamic generation of XML
descriptions based on CPU optional features, instead of having
to have gdbserver carry a bunch of different XML files for each possible
combination of optional features.  (I.e., a continuation of Yao's
earlier work).

I haven't read the patches, but it's likely that you should need
to tweak the individual patches' rationales too.

Thanks,
Pedro Alves