This is the mail archive of the
gdb-patches@sourceware.cygnus.com
mailing list for the GDB project.
Re: [PATCH]: Messy prototypes for supply_gregset and friends.
- To: msnyder at cygnus dot com
- Subject: Re: [PATCH]: Messy prototypes for supply_gregset and friends.
- From: Mark Kettenis <kettenis at wins dot uva dot nl>
- Date: Thu, 25 May 2000 00:02:09 +0200
- CC: gdb-patches at sourceware dot cygnus dot com
- References: <200005242109.OAA11369@seadog.cygnus.com>
Date: Wed, 24 May 2000 14:09:46 -0700 (PDT)
From: msnyder@cygnus.com
There are fifteen GDB modules that each have an implementation of
supply_gregset and its siblings. There are six modules that call
these functions. Unfortunately, not all of the implementations use
the same parameter type for the gregset and/or fpregset arguments.
Most use gregset_t and fpregset_t -- but Solaris uses
prgregset_t and prfpregset_t, and at least one Linux (i386)
uses elf_gregset_t and elf_fpregset_t.
This makes it hard to prototype the functions. Procfs has used an
ugly workaround involving ifdefs and typedefs and autoconf. Everybody
else just lets it slide. This situation has existed long enough.
Using autoconf isn't such a bad idea.
I propose a new file, "gregset.h", which will contain prototypes for
I'd prefer regset.h, or gdb-regset.h. The `g' in gregset stands for
"general purpose" but the file will also contain definitions for
floating-point registers.
this family of functions, as well as a pair of typedefs,
gdb_gregset_t and gdb_fpregset_t. This header file will be included
only by modules that use or define the functions. The default types
will be gregset_t and fpregset_t; any targets that want to use a
different type will define GDB_GREGSET_T and GDB_FPREGSET_T in their
nm.h file. For instance, nm-sun4sol2.h will contain:
#define GDB_GREGSET_T prgregset_t
#define GDB_FPREGSET_T prfpregset_t
Using autoconf we could avoid having to do this except in the really
weird cases. Simply prefer prgregset_t over elf_gregset_t over
gregset_t if GDB_REGSET_T isn't defined.
[yeah, Andrew, I know, this doesn't solve the multi-arch issue...]
Isn't multi-arch irrelevant? supply_regset is only relevant for
native configurations. Unless you'd want to support two different
kinds of ELF core-dumps on one system. Is that what may be happening
on sparc64 systems (e.g. is it possible to generate 32-bit and 64-bit
core-dumps on one systems, and do these use different register set layouts?).
2000-05-24 Michael Snyder <msnyder@seadog.cygnus.com>
* gregset.h: New file. Prototypes for supply_gregset etc.
* procfs.h: Include gregset.h. Delete local prototypes for
supply_gregset etc., and local typedef gdb_gregset_t etc.
* sol-thread.c: Include gregset.h, delete local prototypes,
add appropriate casts to gdb_gregset_t.
* uw-thread.c, lin-thread.c, core-sol2.c, core-regset.c,
sparc-tdep.c, ptx4-nat.c, ppc-linux-nat.c, mipsv4-nat.c,
m88k-nat.c, m68klinux-nat.c, m68k-tdep.c, irix5-nat.c,
irix4-nat.c, ia64-linux-nat.c, i386v4-nat.c, cxux-nat.c,
arm-linux-nat.c, alpha-nat.c: Include gregset.h.
You forgot to include gregset.h, although I can image what it looks
like :-).
Mark