Build xml target descriptions at run time

[Pedro Alves <palves@redhat.com>]

On 04/14/2016 01:21 PM, Walfred Tedeschi wrote:

> Firstly we also agree! :)
> We have to agree upon a strategy and a design for that.
> 
> I would propose that we go in the way it is by now for the patches that
> are under review for me and Michael. Those patches impact technology
> that is already public.
> 
> Together with that we discuss the design on how to stich the target
> descriptions together.
> 
> Would you agree with that?

I would.

> 
> In terms of the design:
> During this time we also proved that it would be possible to have a
> single target description and selecting the features to be added
> according to the feature bits during run time.
> 
> The elegant option is of course the composition of the target
> description under run time. But there is also the consideration of how
> complex it would be.
> 
> Have you already had some thoughts about that? 

Please share your thoughts as well...

> Can you point us to some discussion about the topic?

I'm recalling this being brought up at some Cauldron, and maybe
(ISTR) Luis bringing that up on the gdb list somewhere.  ISTR recall
this coming up for MIPS as well.  But I don't have pointers handy.

I don't have a quick answer.  Below's a couple minutes worth of
thought, all I could spare right now.

Always going through a xml built at run time might be the simplest.
However, even that poses challenges.

The xml-building part itself wouldn't be anything complicated.  Just
something along the lines of:

x86_linux_read_description ()
{
strcat (output, target_xml_header);

if (feature_foo_supported)
  strcat (output, "<xi:include href="feature-foo.xml"/>");
if (feature_bar_supported)
  strcat (output, "<xi:include href="feature-bar.xml"/>");

strcat (output, target_xml_footer);

return output;
}

However, gdb needs its own set of built-in target descriptions as
well, for core file debugging, etc., and always going through
the xml indirection would mean that libexpat becomes a hard requirement
for native and core debugging as well, and, it'd require installing
the xml files in the data-directory, along side gdb.  It's convenient NOT to
have to install the xml files today, but maybe that's not a deal breaker.

Also, then there's the gdbserver side.  gdbserver also makes use of the target
descriptions for more than feeding a xml version back to gdb, and of course
gdbserver doesn't parse the xml files at all.  They're instead converted at
build time to whatever gdbserver needs.  So whatever design we come up with
needs to address this as well.  Going the always-xml direction means that now
gdbserver needs to link with expat and parse the xml files.

Or maybe we could come up with a design that avoids having gdbserver parse
xml, by still converting the feature xml files to C at build time (like, generate
a set of struct target_desc_feature objects (which don't exist today), which would
correspond to each feature that could be xinclude'd), and then at run time compose
a struct target_desc from those struct target_desc_feature object, as well as a xml
file to send back to gdb.

Thanks,
Pedro Alves