This is the mail archive of the gdb-patches@sourceware.cygnus.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Unifying i387 support



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.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]