From: Kevin Buettner <kevinb@redhat.com>
To: Jim Blandy <jimb@redhat.com>, Kevin Buettner <kevinb@redhat.com>
Cc: gdb-patches@sources.redhat.com
Subject: Re: [RFC] s390-tdep.c: Define address class functions for s390x
Date: Fri, 31 Jan 2003 21:07:00 -0000 [thread overview]
Message-ID: <1030131210657.ZM5350@localhost.localdomain> (raw)
In-Reply-To: Jim Blandy <jimb@redhat.com> "Re: [RFC] s390-tdep.c: Define address class functions for s390x" (Jan 31, 3:14pm)
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
next prev parent reply other threads:[~2003-01-31 21:07 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-01-27 23:26 Kevin Buettner
2003-01-31 20:19 ` Jim Blandy
2003-01-31 21:07 ` Kevin Buettner [this message]
2003-02-03 20:46 ` Kevin Buettner
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1030131210657.ZM5350@localhost.localdomain \
--to=kevinb@redhat.com \
--cc=gdb-patches@sources.redhat.com \
--cc=jimb@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox