This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: [RFC] s390-tdep.c: Define address class functions for s390x
- From: Kevin Buettner <kevinb at redhat dot com>
- To: Jim Blandy <jimb at redhat dot com>, Kevin Buettner <kevinb at redhat dot com>
- Cc: gdb-patches at sources dot redhat dot com
- Date: Fri, 31 Jan 2003 14:06:57 -0700
- Subject: Re: [RFC] s390-tdep.c: Define address class functions for s390x
- References: <1030127232625.ZM2026@localhost.localdomain> <vt2adhh84bx.fsf@zenia.red-bean.com>
On Jan 31, 3:14pm, Jim Blandy wrote:
> This looks like a pretty straightforward definition of a new address
> class. Is that right?
Yes.
> Since we only have one target using this facility at the moment, this
> might be premature, but I wonder if it would be worthwhile to provide
> standard, table-driven versions of *_address_class_type_flags_to_name,
> and *_address_class_name_to_type_flags, so that a target could simply
> say:
>
> static address_class_table s390_addr_classes[] = {
> { "mode32", TYPE_FLAG_ADDRESS_CLASS_1 },
> { 0, 0 }
> };
> ...
>
> use_address_class_table_in_gdbarch (gdbarch, s390_addr_classes);
>
> which would install the right methods. Or something like that.
I think this idea is worth purusing once we have more than one target
using the address class facilities.
> Maybe even s390_address_class_type_flags could be handled by the same
> table. I haven't thought it through.
Yes, I agree. For s390, the byte size would be used. However, some
other target my used the address class constant from the DWARF2 info
or, perhaps, some combination of the two. That's why I think it'd
be worth having a couple of other targets under our belts before adding
this machinery.
Kevin