This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [RFC 6/7] Lazily and dynamically create i386-linux target descriptions
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 (齐尧)