[PATCH v2 6/8] Create xml from target descriptions
Alan Hayward
Alan.Hayward@arm.com
Thu Jan 25 16:13:00 GMT 2018
> On 25 Jan 2018, at 13:14, Philipp Rudo <prudo@linux.vnet.ibm.com> wrote:
>
>
> i don't really like print_xml_feature::visit_pre being declared in arch/tdesc.h
> with different implementations in target-descriptions.c and gdbserver/tdesc.c
> while all other visit_* implementations are in arch/tdesc.c. I would prefere
> visit_pre being implemented in arch/tdesc.c, too. Even when it means to add
> some #ifdef GDBSERVER ... #else ... #endif blocks until there is a common tdesc.
Thanks for the review!
A common print_xml_feature would require 4 ifdefs, which would be too messy.
I’ll take a look see if I can communise the tdesc_architecture and tdesc_osabi
interfaces - it should be fairly simple to do.
Once done, I should be able to add a common print_xml_feature without any
ifdefs. Hopefully.
> On 25 Jan 2018, at 15:44, Yao Qi <qiyaoltc@gmail.com> wrote:
>
> Philipp Rudo <prudo@linux.vnet.ibm.com> writes:
>
>> Same for tdesc_type::make_gdb_type (patch #5). But here i would prefer to not
>> even declare the method for GDBserver, i.e.
>>
>> struct tdesc_type
>> {
>>
>> [...]
>>
>> #ifndef GDBSERVER
>> virtual type *make_gdb_type (struct gdbarch *gdbarch) const = 0;
>> #endif
>> };
>>
>> The problem i see with implementing stubs calling error is that you cannot find
>> out you made a mistake until you call the function during run-time. This gives
>> room to nasty bugs which could easily be prevented when there is a compile bug.
>
>
> make_gdb_type and gdbarch shouldn't be put into arch/tdesc.h at all, if
> possible. You can create an sub-class of tdesc_element_visitor in gdb
> side, and create the gdb type by visiting these elements, like this,
>
> class gdb_type_creator : public tdesc_element_visitor
….
Nice idea. I can add an extra patch into the series to do this.
More information about the Gdb-patches
mailing list