Re: [RFC 6/7] Lazily and dynamically create i386-linux target descriptions

[Pedro Alves <palves@redhat.com>]

On 05/18/2017 04:12 PM, Yao Qi wrote:
> Pedro Alves <palves@redhat.com> writes:
> 
>>> +
>>> +  struct xml_and_mask array[] = {
>>> +    { "i386/i386-linux.xml", X86_XSTATE_SSE_MASK },
>>> +    { "i386/i386-mmx-linux.xml", X86_XSTATE_X87_MASK },
>>> +    { "i386/i386-avx-linux.xml", X86_XSTATE_AVX_MASK },
>>> +    { "i386/i386-mpx-linux.xml", X86_XSTATE_MPX_MASK },
>>> +    { "i386/i386-avx-mpx-linux.xml", X86_XSTATE_AVX_MPX_MASK },
>>> +    { "i386/i386-avx-avx512-linux.xml", X86_XSTATE_AVX_AVX512_MASK },
>>> +    { "i386/i386-avx-mpx-avx512-pku-linux.xml",
>>> +      X86_XSTATE_AVX_MPX_AVX512_PKU_MASK },
>>
>> About these xml files.  Is your idea that:
>>
>>  #1 - we remove these xml description files at some point, keeping only
>>       the description fragments which are currently xi:included by the xml
>>       files above?
>>  #2 - or, we'll still continue adding new xml files and grow this
>>       list here?
>>  #3 - or, we'll keep the existing xml files as representative / legacy,
>>       and use them in the unit tests going forward, just to make sure
>>       the machinery builds correct descriptions?
>>
>> (I don't expect to answer to be #2, I just put it there for completeness.)
> 
> In short, #2 and #3.
> 
> IIUC, you are not against "continue adding new xml files" in #2, you are
> against that we have to maintain the list here as we add new xml files.

Well, I wasn't ever expecting we'd end up with #2.  I guess I don't see
the point of going through all of this if we end up with having to add
manually-written xml descriptions covering all feature combinations, anyway?

I could see keeping the xml files pushed in the tree, but make them
generated instead?  It could be gdb that generates them from that
xml_and_mask array.  We'd share the code with gdbserver, so that gdbserver
would generate xml files on the fly to send to gdb.

Or we could do the generation completely outside gdb, with some file
describing the potential combinations (in spirit similar to that xml_and_mask
array), much like we generate the syscall xml files.

> Even we finished the transition for all ports to dynamic tdesc creation,
> we still need to add new xml files to features/ directory for new
> hardware features, because GDBserver needs them (regformats/*.dat need
> them).  We may add i386/i386-avx-mpx-avx512-linux.xml, GDB
> doesn't need it, but GDBserver still needs it.  Given we need to add
> such .xml file, it is better to grow the list so that we can do the
> test.  So the answer is #2.  Suppose one day, we don't need these XML
> files to generate regformats/*.dat for GDBserver, we can remove all
> i386-*linux.xml files except i386-avx-mpx-avx512-pku-linux.xml, but I
> still want to move them to somewhere in testsuite directory to keep them
> as tests.  Then, it becomes #3.

OK.  But if there's no plan to do the gdbserver side of the work,
I kind of call into question the more-complicated state we're getting
into, for an indeterminately long time.

> The purpose of this test is to make sure these lazily/dynamically
> created tdesc (using create_feature_org_gnu_gdb_XXX functions) equal to
> the tdesc created from XML files.  The dynamic tdesc creation is still
> new, needs more tests.
> 
> During the process that we change other targets (amd64, arm, mips, etc)
> to the dynamic tdesc creation, the lists like this are expected to be
> added for each target.
> 
> When we finish the transition to dynamic tdesc creation for all ports,
> and dynamic tdesc creation is quite stable, we can remove all these
> tests and lists, but I prefer to keeping the tests.

I think most ports are not troublesome, WRT to explosion of
target description feature set combinations.  Maybe a better approach
would be to fully transition an architecture all the way to
dynamic generation, gdb and gdbserver?

> 
> Before we remove these tests and lists, we still need to update the
> lists when,
> 
>  1) add a new port with target description, a new list should be added
>  in its -tdep.c file.
>  2) add a new xml target description for the existing port,
> 
> Let me think about how to generate this list instead of manually
> maintain this list.

Thanks,
Pedro Alves