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

Pedro Alves
2018-01-29T18:18:54Z

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"?> <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 \n\n \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 \n\n \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 \n\n \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 \n\n \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 \n\n \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