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]

Re: [PATCH]: Messy prototypes for supply_gregset and friends.


   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

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