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