This is the mail archive of the
gdb-patches@sourceware.cygnus.com
mailing list for the GDB project.
Re: Unifying i387 support
- To: Jim Blandy <jimb@cygnus.com>
- Subject: Re: Unifying i387 support
- From: Andrew Cagney <ac131313@cygnus.com>
- Date: Fri, 09 Jul 1999 11:32:01 +1000
- CC: Eli Zaretskii <eliz@is.elta.co.il>, Mark Kettenis <kettenis@wins.uva.nl>, dj@delorie.com, billm@suburbia.net, gdb-patches@sourceware.cygnus.com
- Organization: Cygnus Solutions
- References: <Pine.SUN.3.91.990707154129.2851X-100000@is> <npoghmtzfj.fsf@zwingli.cygnus.com>
Jim Blandy wrote:
>
> We would like make it possible to write code that accesses the i387
> registers which can be shared amongst all the i386-based targets.
> However, at present, each target lays the registers out differently in
> GDB's map, and #defines different symbols to say where things are.
>
> There are two approaches to fix this.
>
> 1) We could choose a common set of symbols, assign them useful
> semantics, and make each target #define them appropriately. Then,
> generic i387 code can just use them. Each target will continue to
> lay out registers in GDB's map as it pleases.
>
> 2) We could choose a single register layout for all i387 targets to
> use, and require targets to reform the data they receive from the
> OS via ptrace or whatever to fit that layout. Generic i387 code
> can be written to assume this layout.
I also have a strong preference for two.
Another issue to keep in mind is remote.c. It assumes that the order
registers appear in a G packet corresponds to their internal-to-gdb
register numbering. It relies heavily on REGISTER_RAW_SIZE().
I'm not adverse to ideas such as there being a macro that maps a
target-G-packet register onto an internal register. Kind of like the
RAW/VIRTUAL stuff but in the correct place :-). The alternative would
be to parameterize the target with specific call backs.
Andrew