[PATCH] gdb: add an option flag to 'maint print c-tdesc'

Simon Marchi simark@simark.ca
Thu Nov 12 02:26:53 GMT 2020


On 2020-10-21 4:22 a.m., Andrew Burgess wrote:
> GDB has two approaches to generating the target descriptions found in
> gdb/features/, the whole description approach, where the XML file
> contains a complete target description which is then used to generate
> a single C file that builds that target description.  Or, the split
> feature approach, where the XML files contain a single target feature,
> each feature results in a single C file to create that one feature,
> and then a manually written C file is used to build a complete target
> description from individual features.
>
> There's a Makefile, gdb/features/Makefile, which is responsible for
> managing the regeneration of the C files from the XML files.
>
> However, some of the logic the selects between the whole description

second "the" ->  "that"?

> approach, or the split feature approach is actually hard-coded into
> GDB, inside target-descriptions.c:maint_print_c_tdesc_cmd we check the
> path to the incoming XML file and use this to choose which type of C
> file we should generate.
>
> This commit removes this hard coding from GDB, and makes the Makefile
> entirely responsible for choosing the approach.  This makes sense as
> the Makefile already has the XML files partitioned based on which
> approach they should use.
>
> In order to allow this change the 'maint print c-tdesc' command is
> given a new command option '-single-feature', which tells GDB which
> type of C file should be created.  The makefile now supplies this flag
> to GDB.
>
> This did reveal a bug in features/Makefile, the rx.xml file was in the
> wrong list, this didn't matter previously as the actual choice of
> which approach to use was done in GDB.  Now the Makefile decides, so
> placing each XML file in the correct list is critical.
>
> Tested this by doing 'make GDB=/path/to/gdb clean-cfiles cfiles' to
> regenerate all the C files from their XML source.  There are no
> changes after this commit.

That all make sense to me, I think it's a good idea.

Simon


More information about the Gdb-patches mailing list