This is the mail archive of the
gdb-patches@sourceware.cygnus.com
mailing list for the GDB project.
Unifying i387 support
- To: Eli Zaretskii <eliz@is.elta.co.il>, Mark Kettenis <kettenis@wins.uva.nl>, dj@delorie.com, billm@suburbia.net
- Subject: Unifying i387 support
- From: Jim Blandy <jimb@cygnus.com>
- Date: 08 Jul 1999 19:54:56 -0500
- CC: gdb-patches@sourceware.cygnus.com
- References: <Pine.SUN.3.91.990707154129.2851X-100000@is>
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.
Both options can be applied to targets as need and interest arises:
only targets which want to use our generic i387 code need conform to
the interface.
Option 1) is a little simpler: we only need to change the tm-*.h files
and the generic i387 code; no target-specific code needs to change.
Option 2) seems friendlier to multi-arch, since if you are using a
387, you know everything you need to know. Under option 1), different
i387 targets have different layouts, so the multi-arch system needs to
carry more information to the generic code.
Linux already does an arbitrary reformatting between the u area and
GDB's register array; I think most targets do. So that's not a
problem.
Option 2) also appeals to me because it's simpler: I don't see why we
should use multiple layouts for the same information.