Re: [PATCH v4 00/10] Remove gdbserver dependency on xml files

[Simon Marchi <simark at simark dot ca>]

On 2018-03-22 04:44 AM, alan.hayward@arm.com wrote:
> From: Alan Hayward <alan.hayward@arm.com>
> 
> V4 addresses Philipps review comments. I'm fairly confident the issues he
> found on s390 I reproduced on arm32, and have now fixed up - the code now
> ensures xml is not generated for targets using older style descriptions.
> 
> Using git sendmail for the first time, which should sort out the formatting
> issues I've had previously. However, just to the safe I've also pushed to
> my patches to the remote branch users/ahayward/xml4.
> 
> This set adds two new patches to handle when to generate xml (fixing s390
> issues) and the reg_defs vector change.
> 
> Summary:
> 
> For those targets that use new style target descriptions, this set of patches
> removes the dependency on xml files. Namely:
> * Removes inclusion of xml files within gdbserver.
> * Removes the requirement for the .c files in features/ to be generated from
> cached xml files.
> This is made possible by changing xml descriptions generated by gdbserver, so
> that instead of including xml file names, gdbserver now generate a complete
> xml description.
> 
> The second point will be required for aarch64 SVE support, where the register
> size are variable. Creating SVE xml files for every possible vector length
> would not be feasible. Instead the plan for aarch64 SVE is to hand write the
> features/ .c code that would normally be generated from xml.
> 
> Targets which use the older style target descriptions have not been changed.
> 
> 
> XML Generation:
> 
> In existing code, gdbserver uses C code auto generated from xml files to
> create target descriptions. When sending an xml description to GDB, the
> function tdesc_get_features_xml () creates an xml containing the name of the
> original xml file(s). For example:
> 
> <!DOCTYPE target SYSTEM "gdb-target.dtd">
> <target>
>   <architecture>i386</architecture>
>   <osabi>GNU/Linux</osabi>
>   <xi:include href="32bit-core.xml"/>
>   <xi:include href="32bit-sse.xml"/>
>   <xi:include href="32bit-linux.xml"/>
>   <xi:include href="32bit-avx.xml"/>
> </target>
> 
> Upon receipt, GDB then makes requests to gdbserver for the contents of the
> xml files. Gdbserver keeps full copies all the xml files inside the binary.
> 
> This patch series adds common code that allows gdbserver (and gdb) to turn
> a C target description structure into xml.
> Now when asked fort an xml description to gdb, gdbserver turns the entire
> target description structure back into xml, without using any cached files.
> Producing, for example:
> 
> <!DOCTYPE target SYSTEM "gdb-target.dtd">
> <target>
>   <architecture>i386</architecture>
>   <osabi>GNU/Linux</osabi>
>   <feature name="org.gnu.gdb.i386.core">
>     <flags id="i386_eflags" size="4">
>       <field name="CF" start="0" end="0"/>
>       <field name="" start="1" end="1"/>
>       <field name="PF" start="2" end="2"/>
>       <field name="AF" start="4" end="4"/>
> ...etc...
> 
> 
> Patch Contents:
> 
> Patches 3-5 commonise the various target descriptor functionality, allowing
> gdbserver to parse target descriptions in the same way as gdb. This series
> does not commonise target_desc, but this is hopefully a long term goal.
> 
> The eighth patch adds the xml printer, which iterates through the parsing
> generated in the previous patches.
> 
> The other patches are clean up patches.
> 
> 
> 
> Patches have been tested on a make check on x86 targets=all build with
> target boards unix and native-gdbserver. Also built and tested aarch64 and
> Arm32 (which uses old style descriptions)
> In addition, patch six adds new test cases to unit test.

Hi Alan,

I went through the whole series, so I am a bit more familiar with the problem now.
I often see the terms "old" and "new" style target descriptions, but I am not
really familiar with the differences.  Reading this

  https://sourceware.org/gdb/wiki/TargetDescription

this is what I understand:

 - old: An entire target description is pre-generated (as C code) for each possible
   configuration, possibly leading to a combinatorial explosion if there are many
   optional features.
 - new: Each feature is independently generated (as C code) and a hand-written function
   manually assembles the final target description at runtime, adding the necessary
   features based on the CPU features.

Is that right, and is there anything more to it?

Also, more long term-ish question, I never really quite understood the need for the
regformats/*.dat step.  Couldn't we directly go from XML to the generated C files when
building gdb/gdbserver?

Simon