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

[Yao Qi <qiyaoltc@gmail.com>]

Pedro Alves <palves@redhat.com> writes:

> 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?
>

These changes are about GDB, but we still need manually-written xml
files because GDBserver still needs it.  There are still some benefits,

 - GDB binary becomes smaller, see
   https://sourceware.org/ml/gdb-patches/2017-05/msg00299.html

 - We don't have to generate a lot of gdb/features/*.c files, so don't
   need to include them.  In i386-linux, we only need
   features/i386/i386-avx-mpx-avx512-pku-linux.c and all other
   i386*linux.c can be removed.

> 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.
>

I try to stop using the approach we pre-generate them (both xml files
and c 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.

I do plan to do GDBserver side, but I don't have a clear picture on how
to do it yet.  I post this RFC, because this is only about GDB.  This
series can make GDB better and keep GDBserver unchanged, it is still a
progress to me.

>
>> 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?

ARM, MIPS, I386 and S390 have this problem to different extents.  I can
take GDBserver into account at this stage.  I did it last month, but
gave up because it was too brain-damaging.  Let me try again.

-- 
Yao (齐尧)