[Lldb-commits] [PATCH] D63802: Handle nested register definition xml files from the remote serial protocol stub

[Jason Molenda via Phabricator via lldb-commits]

jasonmolenda created this revision.
jasonmolenda added a reviewer: clayborg.
Herald added a project: LLDB.

I was looking at adding support for lldb connecting to qemu's x86_64 RSP stub.  The target definition file we get back from it has a few wrinkles that complicate this, I'm thinking of handling it something like this.

First, it uses nested includes.  We ask for target.xml and we get back

<target><architecture>i386:x86-64</architecture><xi:include href="i386-64bit.xml"/></target>

then we need to ask for i386-64bit.xml which gives us

<feature name="org.gnu.gdb.i386.64bit">

  <xi:include href="i386-64bit-core.xml"/>
  <xi:include href="i386-64bit-sse.xml"/>

</feature>

and requesting those two are going to get us the GPRs and FPRs/vector regs.

The first problem is that ProcessGDBRemote::GetGDBServerRegisterInfo does have support for one level of includes, but it assumes that the target xml file will consist of only registers.

I created a new ProcessGDBRemote::GetGDBServerRegisterInfo method which calls a method that we can call recursively to parse the XML target definitions.  The one problem with THAT is that we fetch the xml file, parse it, then we find the root node -- normally <target> -- and iterate over the child elements that we normally deal with (architecture, osabi, xi:include/include, feature, groups) and for any <feature> nodes, pass the children to ParseRegisters() which looks for <reg> elements.

Now this method ("GetGDBServerRegisterInfoXMLAndProcess", whatever) needs to be prepared to get either the top-level <target> node OR a <feature> node in a child include.  Which is still a bit fragile because, for instance, the <architecture> element is in the top level here but it's possible for the top level xml to just include another xml where we see an <architecture> tag, or whatever?  e.g.

<target>

  <xi:include href="actual-content.xml/">

</target>

{actual-content.xml}

<architecture> i386:x86-64</architecture>
<feature name="org.gnu.gdb.i386.64bit">

  <xi:include href="i386-64bit-core.xml"/>
  <xi:include href="i386-64bit-sse.xml"/>

</feature>

Maybe that's possible?

I have a test file here showing exactly what definitions were being sent.  Also of note is that most of the registers don't get a register grouping by our logic.  The floating point control registers get a group="float", and the mxcsr gets a group="vector", but none of the others do.  It's also interesting to see how the flag bits are defined plus the different vector presentations for the xmm registers.  We're ignoring all of that for now, obviously.

I'll look this patch over more tomorrow, but wanted to give a heads up about what I'm looking at on this one.


Repository:
  rLLDB LLDB

https://reviews.llvm.org/D63802

Files:
  packages/Python/lldbsuite/test/functionalities/gdb_remote_client/TestNestedRegDefinitions.py
  source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp
  source/Plugins/Process/gdb-remote/ProcessGDBRemote.h

-------------- next part --------------
A non-text attachment was scrubbed...
Name: D63802.206575.patch
Type: text/x-patch
Size: 19717 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/lldb-commits/attachments/20190626/f2234400/attachment-0001.bin>