Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
* path for gdb/dwarf2read.c, support 16-bit targets in dwarf-2
@ 2000-04-01  0:00 Stephane Carrez
       [not found] ` <38BB5463.D6E5B75C@cygnus.com>
  0 siblings, 1 reply; 6+ messages in thread
From: Stephane Carrez @ 2000-04-01  0:00 UTC (permalink / raw)
  To: gdb-patches

Hi!

The following patch fixes GDB dwarf-2 reader to support 16-bit address
targets.

In 'dwarf2_build_psymtabs_hard' there was a hack to guess the size of the
target address. We were using the bfd 'elf_size_info::arch_size' member.
This corresponds to the ELF file arch size, not the target address size.
I suggest to use 'bfd_arch_bits_per_address' which really corresponds to
what we need.

Then, in 'read_address', we just have to read 2-bytes addresses.

I've been using this fix for a while with the 68HC11 port.

Can you integrate it?

Thanks,
	Stephane

2000-02-22  Stephane Carrez  <stcarrez@worldnet.fr>

	* dwarf2read.c (dwarf2_build_psymtabs_hard): Use
	bfd_arch_bits_per_address to get the size of addresses.
	(read_address): Read 16-bits addresses.
--- /src/gnu/cygnus/gdb/gdb/dwarf2read.c	Tue Feb 15 21:42:05 2000
+++ gdb/dwarf2read.c	Mon Feb 21 21:17:46 2000
@@ -938,7 +938,7 @@ dwarf2_build_psymtabs_hard (objfile, mai
   CORE_ADDR lowpc, highpc;
 
   /* Number of bytes of any addresses that are signficant */
-  address_significant_size = get_elf_backend_data (abfd)->s->arch_size / 8;
+  address_significant_size = bfd_arch_bits_per_address (abfd) / 8;
 
   info_ptr = dwarf_info_buffer;
   abbrev_ptr = dwarf_abbrev_buffer;
@@ -980,6 +980,7 @@ dwarf2_build_psymtabs_hard (objfile, mai
 		 (long) (beg_of_comp_unit - dwarf_info_buffer));
 	  return;
 	}
+
       if (address_size < address_significant_size)
 	{
 	  error ("Dwarf Error: bad address size (%ld) in compilation unit header (offset 0x%lx + 11).",
@@ -3487,6 +3488,9 @@ read_address (abfd, buf)
 
   switch (address_size)
     {
+    case 2:
+      retval = bfd_get_16 (abfd, (bfd_byte *) buf);
+      break;
     case 4:
       retval = bfd_get_32 (abfd, (bfd_byte *) buf);
       break;
From kettenis@wins.uva.nl Sat Apr 01 00:00:00 2000
From: Mark Kettenis <kettenis@wins.uva.nl>
To: jimb@cygnus.com
Cc: gdb-patches@sourceware.cygnus.com
Subject: Patch for i386-linux-nat.c
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <200001292235.e0TMZNI01759@delius.kettenis.local>
X-SW-Source: 2000-q1/msg00047.html
Content-length: 21211

Hi Jim,

Here is a patch for i386-linux-nat.c.  The main reason for the patch
is to change gregset_t and fpregset_t to elf_gregset_t and
elf_fpregset_t.  There were two different definitions of gregset_t and
fpregset_t on Linux, which were quite different from each other.  The
next glibc (version 2.1.3) will finaly put an end to this braindamage,
but this will break GDB.

While hacking on the file I noticed that there were quite a number of
inconsistencies in the comments and names of variables.  I've gone
over all the comments and rewritten most of them to describe in a more
precise way what they do and to use more consistent terminology.  I
know gratitious reformatting is frowned upon, but I honestly think
that this patch makes the file a lot easier to read.

Mark

PS Before christmas I sent a message about a fix to supply_fpregset to
mask of the reserved bits of the FP control registers:

   http://sourceware.cygnus.com/ml/gdb-patches/1999-q4/msg00375.html

You promised to look at it, but probably forgot about it.  Of course
the patch included in there interferes with the one here.  I'll create
a new patch when after this patch has been applied.


2000-01-29  Mark Kettenis  <kettenis@gnu.org>

	* i386-linux-nat.c: Use elf_gregset_t and elf_fpregset_t instead
	of gregset_t and fpregset_t.  Those are the only names that are
	guaranteed to specify the right types for all supported Linux
	systems out there.
	Various doc fixes and gratitious local variable renames, all in an
	attempt to stress similarities between the code and unify the
	terminology used.
	(regmap): Remove trailing comma.
	(FPREG_ADDR): Renamed from FPREGSET_T_FPREG_ADDR.
	(convert_to_gregset): Make static.  Remove GDB_REGS argument.  It
	is unnecessary and wasn't used anyway.  All callers changed.
	(convert_to_fpregset, convert_to_xfpregset): Likewise.
	

Index: gdb/i386-linux-nat.c
===================================================================
RCS file: /cvs/gdb/gdb/gdb/i386-linux-nat.c,v
retrieving revision 1.1.1.8
diff -u -r1.1.1.8 i386-linux-nat.c
--- gdb/i386-linux-nat.c	2000/01/18 00:54:14	1.1.1.8
+++ gdb/i386-linux-nat.c	2000/01/29 22:34:40
@@ -20,7 +20,7 @@
 #include "inferior.h"
 #include "gdbcore.h"
 
-/* For i386_linux_skip_solib_resolver */
+/* For i386_linux_skip_solib_resolver.  */
 #include "symtab.h"
 #include "frame.h"
 #include "symfile.h"
@@ -34,27 +34,40 @@
 #include <sys/reg.h>
 #endif
 
-/*
- * Some systems (Linux) may have threads implemented as pseudo-processes, 
- * in which case we may be tracing more than one process at a time.
- * In that case, inferior_pid will contain the main process ID and the 
- * individual thread (process) id mashed together.  These macros are 
- * used to separate them out.  The definitions may be overridden in tm.h
- */
+/* On Linux, threads are implemented as pseudo-processes, in which
+   case we may be tracing more than one process at a time.  In that
+   case, inferior_pid will contain the main process ID and the
+   individual thread (process) ID mashed together.  These macros are
+   used to separate them out.  These definitions should be overridden
+   if thread support is included.  */
 
 #if !defined (PIDGET)	/* Default definition for PIDGET/TIDGET.  */
-#define PIDGET(PID)	PID
-#define TIDGET(PID)	0
+# define PIDGET(PID)	PID
+# define TIDGET(PID)	0
 #endif
 
-/* This is a duplicate of the table in i386-xdep.c. */
 
+/* The register sets used in Linux ELF core-dumps are identical to the
+   register sets in `struct user' that was used for in a.out
+   core-dumps, that is also used by `ptrace'.  The corresponding types
+   are `elf_gregset_t' for the general-purpose registers (with
+   `elf_greg_t' the type of a single GP register) and `elf_fpregset_t'
+   for the floating-point registers.
+
+   Those types used to be available under the names `gregset_t' and
+   `fpregset_t' too, and this file used those names in the past.  But
+   those names are now used for the register sets used in the
+   `mcontext_t' type, and have a different size and layout.  */
+
+
+/* Mapping between the general-purpose registers in `struct user'
+   format and GDB's register file layout.  */
 static int regmap[] = 
 {
   EAX, ECX, EDX, EBX,
   UESP, EBP, ESI, EDI,
   EIP, EFL, CS, SS,
-  DS, ES, FS, GS,
+  DS, ES, FS, GS
 };
 
 
@@ -92,40 +105,31 @@
 
 
 \f
-/* Transfering the general registers between GDB, inferiors and core files.  */
+/* Transfering the general-purpose registers between GDB, inferiors
+   and core files.  */
 
-/* Given a pointer to a general register set in struct user format
-   (gregset_t *), unpack the register contents and supply them as
-   gdb's idea of the current register values. */
+/* Fill GDB's register file with the genereal-purpose register values
+   in *GREGSETP.  */
 void
-supply_gregset (gregsetp)
-     gregset_t *gregsetp;
+supply_gregset (elf_gregset_t *gregsetp)
 {
-  register int regi;
-  register greg_t *regp = (greg_t *) gregsetp;
+  elf_greg_t *regp = (elf_greg_t *) gregsetp;
+  int regi;
 
   for (regi = 0; regi < NUM_GREGS; regi++)
-    {
-      supply_register (regi, (char *) (regp + regmap[regi]));
-    }
+    supply_register (regi, (char *) (regp + regmap[regi]));
 }
 
 
-/* Fill in a gregset_t object with selected data from a gdb-format
-   register file.
-   - GREGSETP points to the gregset_t object to be filled.
-   - GDB_REGS points to the GDB-style register file providing the data.
-   - VALID is an array indicating which registers in GDB_REGS are
-     valid; the parts of *GREGSETP that would hold registers marked
-     invalid in GDB_REGS are left unchanged.  If VALID is zero, all
-     registers are assumed to be valid.  */
-void
-convert_to_gregset (gregset_t *gregsetp,
-		    char *gdb_regs,
-		    signed char *valid)
+/* Convert the valid general-purpose register values in GDB's register
+   file to `struct user' format and store them in *GREGSETP.  The
+   array VALID indicates which register values are valid.  If VALID is
+   NULL, all registers are assumed to be valid.  */
+static void
+convert_to_gregset (elf_gregset_t *gregsetp, signed char *valid)
 {
+  elf_greg_t *regp = (elf_greg_t *) gregsetp;
   int regi;
-  register greg_t *regp = (greg_t *) gregsetp;
 
   for (regi = 0; regi < NUM_GREGS; regi++)
     if (! valid || valid[regi])
@@ -133,64 +137,70 @@
 }
 
 
-/* Store GDB's value for REGNO in *GREGSETP.  If REGNO is -1, do all
-   of them.  */
+/* Fill register REGNO (if it is a general-purpose register) in
+   *GREGSETPS with the value in GDB's register file.  If REGNO is -1,
+   do this for all registers.  */
 void
-fill_gregset (gregset_t *gregsetp,
-	      int regno)
+fill_gregset (elf_gregset_t *gregsetp, int regno)
 {
   if (regno == -1)
-    convert_to_gregset (gregsetp, registers, 0);
-  else if (regno >= 0 && regno < NUM_GREGS)
     {
+      convert_to_gregset (gregsetp, NULL);
+      return;
+    }
+
+  if (GETREGS_SUPPLIES (regno))
+    {
       signed char valid[NUM_GREGS];
+
       memset (valid, 0, sizeof (valid));
       valid[regno] = 1;
-      convert_to_gregset (gregsetp, registers, valid);
+
+      convert_to_gregset (gregsetp, valid);
     }
 }
 
 
-/* Read the general registers from the process, and store them
-   in registers[].  */
+/* Fetch all general-purpose registers from process/thread TID and
+   store their values in GDB's register file.  */
 static void
 fetch_regs (int tid)
 {
-  int ret, regno;
-  gregset_t buf;
+  elf_gregset_t regs;
+  int ret;
 
-  ret = ptrace (PTRACE_GETREGS, tid, 0, (int) &buf);
+  ret = ptrace (PTRACE_GETREGS, tid, 0, (int) &regs);
   if (ret < 0)
     {
-      warning ("Couldn't get registers");
+      warning ("Couldn't get registers.");
       return;
     }
 
-  supply_gregset (&buf);
+  supply_gregset (&regs);
 }
 
 
-/* Set the inferior's general registers to the values in registers[]
-   --- but only those registers marked as valid.  */
+/* Store all valid general-purpose registers in GDB's register file
+   into the process/thread specified by TID.  */
 static void
 store_regs (int tid)
 {
-  int ret, regno;
-  gregset_t buf;
+  elf_gregset_t regs;
+  int ret;
 
-  ret = ptrace (PTRACE_GETREGS, tid, 0, (int) &buf);
+  ret = ptrace (PTRACE_GETREGS, tid, 0, (int) &regs);
   if (ret < 0)
     {
-      warning ("Couldn't get registers");
+      warning ("Couldn't get registers.");
       return;
     }
 
-  convert_to_gregset (&buf, registers, register_valid);
+  convert_to_gregset (&regs, register_valid);
 
-  ret = ptrace (PTRACE_SETREGS, tid, 0, (int)buf);
+  ret = ptrace (PTRACE_SETREGS, tid, 0, (int) &regs);
   if (ret < 0)
     {
-      warning ("Couldn't write registers");
+      warning ("Couldn't write registers.");
       return;
     }
 }
@@ -199,20 +209,19 @@
 \f
 /* Transfering floating-point registers between GDB, inferiors and cores.  */
 
-/* What is the address of st(N) within the fpregset_t structure F?  */
-#define FPREGSET_T_FPREG_ADDR(f, n) \
-  ((char *) &(f)->st_space + (n) * 10)
+/* What is the address of st(N) within the floating-point register set F?  */
+#define FPREG_ADDR(f, n) ((char *) &(f)->st_space + (n) * 10)
 
 /* Fill GDB's register file with the floating-point register values in
    *FPREGSETP.  */
 void 
-supply_fpregset (fpregset_t *fpregsetp)
+supply_fpregset (elf_fpregset_t *fpregsetp)
 {
-  int i;
+  int reg;
 
   /* Supply the floating-point registers.  */
-  for (i = 0; i < 8; i++)
-    supply_register (FP0_REGNUM + i, FPREGSET_T_FPREG_ADDR (fpregsetp, i));
+  for (reg = 0; reg < 8; reg++)
+    supply_register (FP0_REGNUM + reg, FPREG_ADDR (fpregsetp, reg));
 
   supply_register (FCTRL_REGNUM, (char *) &fpregsetp->cwd);
   supply_register (FSTAT_REGNUM, (char *) &fpregsetp->swd);
@@ -234,27 +243,21 @@
 }
 
 
-/* Fill in an fpregset_t structure with selected data from a
-   gdb-format register file.
-   - FPREGSETP points to the structure to be filled. 
-   - GDB_REGS points to the GDB-style register file providing the data.
-   - VALID is an array indicating which registers in GDB_REGS are
-     valid; the parts of *FPREGSETP that would hold registers marked
-     invalid in GDB_REGS are left unchanged.  If VALID is zero, all
-     registers are assumed to be valid.  */
-void
-convert_to_fpregset (fpregset_t *fpregsetp,
-		     char *gdb_regs,
-		     signed char *valid)
+/* Convert the valid floating-point register values in GDB's register
+   file to `struct user' format and store them in *FPREGSETP.  The
+   array VALID indicates which register values are valid.  If VALID is
+   NULL, all registers are assumed to be valid.  */
+static void
+convert_to_fpregset (elf_fpregset_t *fpregsetp, signed char *valid)
 {
-  int i;
+  int reg;
 
   /* Fill in the floating-point registers.  */
-  for (i = 0; i < 8; i++)
-    if (!valid || valid[i])
-      memcpy (FPREGSET_T_FPREG_ADDR (fpregsetp, i),
-	      &registers[REGISTER_BYTE (FP0_REGNUM + i)],
-	      REGISTER_RAW_SIZE(FP0_REGNUM + i));
+  for (reg = 0; reg < 8; reg++)
+    if (!valid || valid[reg])
+      memcpy (FPREG_ADDR (fpregsetp, reg),
+	      &registers[REGISTER_BYTE (FP0_REGNUM + reg)],
+	      REGISTER_RAW_SIZE(FP0_REGNUM + reg));
 
 #define fill(MEMBER, REGNO)						\
   if (! valid || valid[(REGNO)])					\
@@ -283,68 +286,78 @@
 }
 
 
-/* Given a pointer to a floating point register set in (fpregset_t *)
-   format, update all of the registers from gdb's idea of the current
-   floating point register set.  */
-
+/* Fill register REGNO (if it is a floating-point register) in
+   *FPREGSETP with the value in GDB's register file.  If REGNO is -1,
+   do this for all registers.  */
 void
-fill_fpregset (fpregset_t *fpregsetp,
-	       int regno)
+fill_fpregset (elf_fpregset_t *fpregsetp, int regno)
 {
-  convert_to_fpregset (fpregsetp, registers, 0);
+  if (regno == -1)
+    {
+      convert_to_fpregset (fpregsetp, NULL);
+      return;
+    }
+
+  if (GETFPREGS_SUPPLIES(regno))
+    {
+      signed char valid[MAX_NUM_REGS];
+      
+      memset (valid, 0, sizeof (valid));
+      valid[regno] = 1;
+	      
+      convert_to_fpregset (fpregsetp, valid);
+    }
 }
 
 
-/* Get the whole floating point state of the process and store the
-   floating point stack into registers[].  */
+/* Fetch all floating-point registers from process/thread TID and store
+   thier values in GDB's register file.  */
 static void
 fetch_fpregs (int tid)
 {
-  int ret, regno;
-  fpregset_t buf;
+  elf_fpregset_t fpregs;
+  int ret;
 
-  ret = ptrace (PTRACE_GETFPREGS, tid, 0, (int) &buf);
+  ret = ptrace (PTRACE_GETFPREGS, tid, 0, (int) &fpregs);
   if (ret < 0)
     {
-      warning ("Couldn't get floating point status");
+      warning ("Couldn't get floating point status.");
       return;
     }
 
-  /* ptrace fills an fpregset_t, so we can use the same function we do
-     for core files.  */
-  supply_fpregset (&buf);
+  supply_fpregset (&fpregs);
 }
 
 
-/* Set the inferior's floating-point registers to the values in
-   registers[] --- but only those registers marked valid.  */
+/* Store all valid floating-point registers in GDB's register file
+   into the process/thread specified by TID.  */
 static void
 store_fpregs (int tid)
 {
+  elf_fpregset_t fpregs;
   int ret;
-  fpregset_t buf;
 
-  ret = ptrace (PTRACE_GETFPREGS, tid, 0, (int) &buf);
+  ret = ptrace (PTRACE_GETFPREGS, tid, 0, (int) &fpregs);
   if (ret < 0)
     {
-      warning ("Couldn't get floating point status");
+      warning ("Couldn't get floating point status.");
       return;
     }
 
-  convert_to_fpregset (&buf, registers, register_valid);
+  convert_to_fpregset (&fpregs, register_valid);
 
-  ret = ptrace (PTRACE_SETFPREGS, tid, 0, (int) &buf);
+  ret = ptrace (PTRACE_SETFPREGS, tid, 0, (int) &fpregs);
   if (ret < 0)
     {
-      warning ("Couldn't write floating point status");
+      warning ("Couldn't write floating point status.");
       return;
     }
 }
 
+
 \f
 /* Transfering floating-point and SSE registers to and from GDB.  */
 
-
 /* PTRACE_GETXFPREGS is a Cygnus invention, since we wrote our own
    Linux kernel patch for SSE support.  That patch may or may not
    actually make it into the official distribution.  If you find that
@@ -353,6 +366,9 @@
    you can delete this code.  */
 
 #ifdef HAVE_PTRACE_GETXFPREGS
+
+/* Fill GDB's register file with the floating-point and SSE register
+   values in *XFPREGS.  */
 static void
 supply_xfpregset (struct user_xfpregs_struct *xfpregs)
 {
@@ -389,9 +405,12 @@
 }
 
 
+/* Convert the valid floating-point and SSE registers in GDB's
+   register file to `struct user' format and store them in *XFPREGS.
+   The array VALID indicates which registers are valid.  If VALID is
+   NULL, all registers are assumed to be valid.  */
 static void
 convert_to_xfpregset (struct user_xfpregs_struct *xfpregs,
-		      char *gdb_regs,
 		      signed char *valid)
 {
   int reg;
@@ -437,13 +456,14 @@
 }
 
 
-/* Make a PTRACE_GETXFPREGS request, and supply all the register
-   values that yields to GDB.  */
+/* Fetch all registers covered by the PTRACE_SETXFPREGS request from
+   process/thread TID and store their values in GDB's register file.
+   Return non-zero if successful, zero otherwise.  */
 static int
 fetch_xfpregs (int tid)
 {
-  int ret;
   struct user_xfpregs_struct xfpregs;
+  int ret;
 
   if (! have_ptrace_getxfpregs) 
     return 0;
@@ -457,7 +477,7 @@
 	  return 0;
 	}
 
-      warning ("couldn't read floating-point and SSE registers.");
+      warning ("Couldn't read floating-point and SSE registers.");
       return 0;
     }
 
@@ -466,13 +486,14 @@
 }
 
 
-/* Send all the valid register values in GDB's register file covered
-   by the PTRACE_SETXFPREGS request to the inferior.  */
+/* Store all valid registers in GDB's register file covered by the
+   PTRACE_SETXFPREGS request into the process/thread specified by TID.
+   Return non-zero if successful, zero otherwise.  */
 static int
 store_xfpregs (int tid)
 {
-  int ret;
   struct user_xfpregs_struct xfpregs;
+  int ret;
 
   if (! have_ptrace_getxfpregs)
     return 0;
@@ -486,11 +507,11 @@
 	  return 0;
 	}
 
-      warning ("couldn't read floating-point and SSE registers.");
+      warning ("Couldn't read floating-point and SSE registers.");
       return 0;
     }
 
-  convert_to_xfpregset (&xfpregs, registers, register_valid);
+  convert_to_xfpregset (&xfpregs, register_valid);
 
   if (ptrace (PTRACE_SETXFPREGS, tid, 0, &xfpregs) < 0)
     {
@@ -530,26 +551,26 @@
 
 #endif
 
+
 \f
 /* Transferring arbitrary registers between GDB and inferior.  */
-
-/* Fetch registers from the child process.
-   Fetch all if regno == -1, otherwise fetch all ordinary
-   registers or all floating point registers depending
-   upon the value of regno. */
 
+/* Fetch register REGNO from the child process.  If REGNO is -1, do
+   this for all registers (including the floating point and SSE
+   registers).  */
 void
 fetch_inferior_registers (int regno)
 {
-  /* linux lwp id's are process id's */
   int tid;
 
+  /* Linux LWP ID's are process ID's.  */
   if ((tid = TIDGET (inferior_pid)) == 0)
-    tid = inferior_pid;		/* not a threaded program */
+    tid = inferior_pid;		/* Not a threaded program.  */
 
-  /* Use the xfpregs requests whenever possible, since they transfer
-     more registers in one system call, and we'll cache the results.
-     But remember that fetch_xfpregs can fail, and return zero.  */
+  /* Use the PTRACE_GETXFPREGS request whenever possible, since it
+     transfers more registers in one system call, and we'll cache the
+     results.  But remember that fetch_xfpregs can fail, and return
+     zero.  */
   if (regno == -1)
     {
       fetch_regs (tid);
@@ -586,24 +607,20 @@
 }
 
 
-/* Store our register values back into the inferior.
-   If REGNO is -1, do this for all registers.
-   Otherwise, REGNO specifies which register, which
-   then determines whether we store all ordinary
-   registers or all of the floating point registers. */
-
+/* Store register REGNO back into the child process.  If REGNO is -1,
+   do this for all registers (including the floating point and SSE
+   registers).  */
 void
-store_inferior_registers (regno)
-     int regno;
+store_inferior_registers (int regno)
 {
-  /* linux lwp id's are process id's */
   int tid;
 
+  /* Linux LWP ID's are process ID's.  */
   if ((tid = TIDGET (inferior_pid)) == 0)
-    tid = inferior_pid;		/* not a threaded program */
+    tid = inferior_pid;		/* Not a threaded program.  */
 
-  /* Use the xfpregs requests whenever possible, since they transfer
-     more registers in one system call.  But remember that
+  /* Use the PTRACE_SETXFPREGS requests whenever possibl, since it
+     transfers more registers in one system call.  But remember that
      store_xfpregs can fail, and return zero.  */
   if (regno == -1)
     {
@@ -626,7 +643,8 @@
 	return;
 
       /* Either our processor or our kernel doesn't support the SSE
-	 registers, so just write the FP registers in the traditional way.  */
+	 registers, so just write the FP registers in the traditional
+	 way.  */
       store_fpregs (tid);
       return;
     }
@@ -651,26 +669,25 @@
    register contents.  CORE_REG_SIZE is its size.
 
    WHICH says which register set corelow suspects this is:
-   0 --- the general register set, in gregset format
-   2 --- the floating-point register set, in fpregset format
-   3 --- the extended floating-point register set, in struct
-         user_xfpregs_struct format
+     0 --- the general-purpose register set, in elf_gregset_t format
+     2 --- the floating-point register set, in elf_fpregset_t format
+     3 --- the extended floating-point register set, in struct
+           user_xfpregs_struct format
 
-   DUMMY isn't used on Linux.  */
+   REG_ADDR isn't used on Linux.  */
 static void
 i386_linux_fetch_core_registers (char *core_reg_sect,
 				 unsigned core_reg_size,
-				 int which,
-				 CORE_ADDR dummy)
+				 int which, CORE_ADDR reg_addr)
 {
-  gregset_t gregset;
-  fpregset_t fpregset;
+  elf_gregset_t gregset;
+  elf_fpregset_t fpregset;
 
   switch (which)
     {
     case 0:
       if (core_reg_size != sizeof (gregset))
-	warning ("wrong size gregset struct in core file");
+	warning ("Wrong size gregset in core file.");
       else
 	{
 	  memcpy (&gregset, core_reg_sect, sizeof (gregset));
@@ -680,7 +697,7 @@
 
     case 2:
       if (core_reg_size != sizeof (fpregset))
-	warning ("wrong size fpregset struct in core file");
+	warning ("Wrong size fpregset in core file.");
       else
 	{
 	  memcpy (&fpregset, core_reg_sect, sizeof (fpregset));
@@ -691,9 +708,10 @@
 #ifdef HAVE_PTRACE_GETXFPREGS
       {
 	struct user_xfpregs_struct xfpregset;
+
       case 3:
-	if (core_reg_size != sizeof (struct user_xfpregs_struct))
-	  warning ("wrong size user_xfpregs_struct in core file");
+	if (core_reg_size != sizeof (xfpregset))
+	  warning ("Wrong size user_xfpregs_struct in core file.");
 	else
 	  {
 	    memcpy (&xfpregset, core_reg_sect, sizeof (xfpregset));
@@ -720,6 +738,7 @@
   i386_linux_fetch_core_registers,	/* core_read_registers */
   NULL					/* next */
 };
+
 
 \f
 /* Calling functions in shared libraries.  */
From ac131313@cygnus.com Sat Apr 01 00:00:00 2000
From: Andrew Cagney <ac131313@cygnus.com>
To: Mark Kettenis <kettenis@wins.uva.nl>
Cc: gdb-patches@sourceware.cygnus.com
Subject: Re: [PATCH] Replace ../include/wait.h with gdb_wait.h.
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <38A244B4.DF8E231C@cygnus.com>
References: <38A12872.13D194C4@cygnus.com> <200002091429.e19ETk916570@delius.kettenis.local>
X-SW-Source: 2000-q1/msg00108.html
Content-length: 676

FYI,

Mark Kettenis wrote:
> There is a problem with `linux-thread.c', where `gdb_wait.h' is included
> before config.h.  This means that HAVE_SYS_WAIT_H and HAVE_WAIT_H are
> still undefined and the system headers are never used.

FYI, I've comitted just this bit.  Per other e-mail, the rest will
follow.

	Andrew


> +#include "defs.h"
>  #include <sys/types.h> /* for pid_t */
>  #include <sys/ptrace.h> /* for PT_* flags */
>  #include "gdb_wait.h" /* for WUNTRACED and __WCLONE flags */
>  #include <signal.h> /* for struct sigaction and NSIG */
>  #include <sys/utsname.h>
> 
> -#include "defs.h"
>  #include "target.h"
>  #include "inferior.h"
>  #include "gdbcore.h"
From nsd@cygnus.com Sat Apr 01 00:00:00 2000
From: nsd@cygnus.com
To: john@feith.com
Cc: cgf@cygnus.com, eliz@delorie.com, gdb-patches@sourceware.cygnus.com, jimb@cygnus.com, msnyder@cygnus.com
Subject: Re: GDB 4.17 Patch for stack aligned i386 code
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <200003250007.AAA07650@nog.bosbc.com>
References: <200003242355.SAA14221@jwlab.FEITH.COM>
X-SW-Source: 2000-q1/msg01011.html
Content-length: 520

>Are you handling non-leaf functions even when the stack pointer is changing?

Yes.  It works by emulating instructions to figure out the stack pointer
on entry to or exit from the function.  The opcodes library, with a few
minor changes, provides the instruction information in an
architecture-independent format.

>Does your patch handle functions where the prologue uses "andl" to align
>the frame?

I don't know.  Do you happen to have an example of how to generate such
code?  I'd be interested in trying it.

Nick
From kevinb@cygnus.com Sat Apr 01 00:00:00 2000
From: Kevin Buettner <kevinb@cygnus.com>
To: Andrew Cagney <ac131313@cygnus.com>
Cc: gdb-patches@sourceware.cygnus.com
Subject: Re: [PATCH RFA] Configury changes for IA-64
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <1000321051613.ZM20603@ocotillo.lan>
References: <1000321003058.ZM20160@ocotillo.lan> <38D6FD73.AEF13B2D@cygnus.com> <ac131313@cygnus.com>
X-SW-Source: 2000-q1/msg00848.html
Content-length: 175

On Mar 21,  3:41pm, Andrew Cagney wrote:

> PS, should the configure.tgt addition appear after ``i960-*''?

Right you are.  I'll fix it before checking it in.

Thanks,

Kevin
From ac131313@cygnus.com Sat Apr 01 00:00:00 2000
From: Andrew Cagney <ac131313@cygnus.com>
To: GDB Patches <gdb-patches@sourceware.cygnus.com>
Cc: elena@cygnus.com
Subject: [MAINT] Expand readline/ maintaners
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <38C21E40.34CF06CB@cygnus.com>
X-SW-Source: 2000-q1/msg00521.html
Content-length: 1252

FYI,

I've added the following.

	Andrew
Sun Mar  5 19:40:27 2000  Andrew Cagney  <cagney@b1.cygnus.com>

	* MAINTAINERS (readline/): Expand to include host maintainers.

Index: MAINTAINERS
===================================================================
RCS file: /cvs/src/src/gdb/MAINTAINERS,v
retrieving revision 1.20
diff -p -r1.20 MAINTAINERS
*** MAINTAINERS	2000/03/04 06:27:00	1.20
--- MAINTAINERS	2000/03/05 08:41:50
*************** Core: Generic components used by all of 
*** 80,86 ****
  generic arch support	Andrew Cagney		cagney@cygnus.com
  target vector		Andrew Cagney		cagney@cygnus.com
  main (main.c, top.c)	Elena Zannoni		ezannoni@cygnus.com
- readline		Elena Zannoni		ezannoni@cygnus.com
  event loop		Elena Zannoni           ezannoni@cygnus.com
  generic symtabs		Jim Blandy		jimb@cygnus.com
  dwarf readers		Jim Blandy		jimb@cygnus.com
--- 80,85 ----
*************** mmalloc/		ALL Host maintainers
*** 133,138 ****
--- 132,142 ----
  
  sim/			See sim/MAINTAINERS, co-ordinated by:
  			Frank Ch. Eigler	fche@cygnus.com
+ 
+ readline/		Master version: ftp://ftp.cwru.edu/pub/bash/
+ 			Elena Zannoni		ezannoni@cygnus.com
+ 			Host maintainers (host dependant parts)
+ 			(but get your changes into the master version)
  
  
  
From eliz@delorie.com Sat Apr 01 00:00:00 2000
From: Eli Zaretskii <eliz@delorie.com>
To: msnyder@cygnus.com
Cc: dima@Chg.RU, gdb-patches@sourceware.cygnus.com
Subject: Re: typo in gdb.texinfo
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <200003160953.EAA01859@indy.delorie.com>
References: <200003151932.WAA39200@netserv1.chg.ru> <38CFE64A.2BBB@cygnus.com>
X-SW-Source: 2000-q1/msg00735.html
Content-length: 482

> I think the purpose of having GDBINIT be a variable is
> because it has a different filename on windows/CYGWIN.
> Isn't it called "gdb.ini" or something?

AFAIK, `gdb.ini' is used in the DJGPP version only (Windows does allow
leading dots in file names, but DOS doesn't), and the different name
is explicitly mentioned in the manual, see the nodes "Mode Options"
and "Command Files".

So I don't think we need to hide this name behind a variable, at least
not because of Windows.
From cgf@cygnus.com Sat Apr 01 00:00:00 2000
From: cgf@cygnus.com (Chris Faylor)
To: gdb-patches@sourceware.cygnus.com
Subject: Re: Add support for WinCE toolchains
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <88vbe5$4r5$1@cronkite.cygnus.com>
References: <200002222350.PAA09035@elmo.cygnus.com> <38B32684.530F4F66@apple.com> <200002230024.TAA11216@envy.delorie.com> <38B32E01.34616D70@apple.com>
X-SW-Source: 2000-q1/msg00319.html
Content-length: 1875

In article < 38B32E01.34616D70@apple.com >, Stan Shebs  <shebs@apple.com> wrote:
>DJ Delorie wrote:
>> 
>> > This should get a special mention in gdb/NEWS, and ideally in README
>> > also; this is one of those situations where you'll be glad you
>> > forestalled a slew of complaints and bug reports by documenting it
>> > in several places.
>> 
>> Is it acceptable to add notes to configure, so that if you said
>> "./configure --target=arm-pe" it could print out "Note: if you wanted
>> Windows CE, use arm-wince-pe instead" ?  Maybe in the toplevel configure?
>
>My kneejerk is to be unenthusiastic, although I'm not sure why.  I guess it
>seems to me that notes in configure should be more about issues that are
>more directly related to the configure script, while in this case (IIRC) the
>differences are more in the sources.  But that's a pretty weak theoretical
>argument, and if the extra warning sets even one user on the path of rightness,
>then it's worthwhile to add.

Um.  I'm working with Andrew on finalizing the wince stuff.  Getting
this checked into sourceware just now is premature.  One reason is that
it doesn't work on the ARM yet.

One of the things I've done is to regularize the name of files that I
used.  Everything has a "wince" in it now since the WinCE version of PE
is apparently non-standard.  I've also moved WinCE-specific code out of
the generic target files into their own files.

If there is going to be a note, it should go in a top-level README.  gdb
doesn't currently care if the name of the target is arm-foo-wince.  It's
bfd that cares, I believe.

Anyway, I would request that this patch be ignored for now.  Andrew will
handle this all in a future merge.
-- 
cgf@cygnus.com                        Cygnus Solutions, a Red Hat company
http://sourcware.cygnus.com/          http://www.redhat.com/
From kettenis@wins.uva.nl Sat Apr 01 00:00:00 2000
From: Mark Kettenis <kettenis@wins.uva.nl>
To: shebs@shebs.cnchost.com
Cc: dima@Chg.RU, eliz@is.elta.co.il, gdb-patches@sourceware.cygnus.com
Subject: Re: patch for gdb.texinfo
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <200001281909.e0SJ97M18034@delius.kettenis.local>
References: <200001281642.TAA04176@netserv1.chg.ru> <3891CD13.A68984BA@shebs.cnchost.com>
X-SW-Source: 2000-q1/msg00045.html
Content-length: 1510

   Date: Fri, 28 Jan 2000 09:08:52 -0800
   From: Stan Shebs <shebs@shebs.cnchost.com>

   (Hi everybody!)

Welcome back Stan!

   Dmitry Sivachenko wrote:

   > I think we should use new features of texinfo.  May be in future
   > versions typeseting @env and @command will differ from the
   > current behaviour.  By the way, FreeBSD team already updated
   > texinfo to 4.0 in base distribution.

   I disagree here.  We do have to worry about backward compatibility,
   just as we had to support K&R compilers for a long time, and just
   as we support many old OS versions.  Certainly many GDB users would
   be disappointed if we trashed Linux support for any kernel older
   than, say, 2.2.5!

Well, it's slightly more complicated than that.

It is standard GNU procedure to include the info files in the
distribution.  So the user doesn't need makeinfo when building from an
official release.  It is also standard procedure to include
texinfo.tex in the distribution, thus for making a printed manual an
up-to-date texinfo isn't necessary either.

Thus someone who isn't actively hacking on package doesn't need texinfo at
all.

Cygnus might do things a little different.  Is GDB still distributed
with texinfo included?  The CVS version suggests that this is the
case.  Since the version in CVS is older than texinfo 4.0, using new
features would not be very convenient!  Maybe it is time for an
upgrade?  Because I think that if using new feature improves the
markup we should try to use them.

Mark
From ac131313@cygnus.com Sat Apr 01 00:00:00 2000
From: Andrew Cagney <ac131313@cygnus.com>
To: Stephane Carrez <Stephane.Carrez@worldnet.fr>
Cc: gdb-patches@sourceware.cygnus.com, Jim Blandy <jimb@cygnus.com>
Subject: Re: path for gdb/dwarf2read.c, support 16-bit targets in dwarf-2
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <38C225F3.9E236A55@cygnus.com>
References: <38B2F3D3.54CF0AF0@worldnet.fr> <38BB5463.D6E5B75C@cygnus.com> <38C0D9D9.70987863@worldnet.fr>
X-SW-Source: 2000-q1/msg00525.html
Content-length: 1747

Stephane Carrez wrote:
> 
> Hi!
> 
> Andrew Cagney wrote:
> >
> > As for the change:
> >
> > > -  address_significant_size = get_elf_backend_data (abfd)->s->arch_size / 8;
> > > +  address_significant_size = bfd_arch_bits_per_address (abfd) / 8;
> >
> > I'm not so sure.  Does bfd_arch_bits_per_address() return 16 while the
> > elf data arch_size indicate something else (elf32 vs elf16?)
> >
> > I've attatched some references to when a similar problem was discussed
> > for a 64 bit target with 32 bit ELF binaries.
> >
> > Jim?
> >
> >         Andrew
> >
> > http://sourceware.cygnus.com/ml/gdb-patches/1999-q4/msg00267.html
> > http://sourceware.cygnus.com/ml/gdb-patches/1999-q4/msg00263.html
> >
> Yes
> 
> It returns the value held by the cpu-* bfd_arch_info_type structure:
> 
>   return abfd->arch_info->bits_per_address;
> 
> So, it's not related to the ELF format but really concerns the CPU address.
> The mips architecture is able to return either 32 or 64 depending on
> the CPU flavor.
> 
> From: Andrew Cagney <ac131313 at cygnus dot com>:
> > Is there a way of determining if an object file is 32 or 64 bit?  (eg
> > elf32/elf64, aout32 vs aout64).
> > Perhaphs bfd_arch_bits_per_address(ABFD) is correct?
> I think it's not correct but you should rather do:
> 
>         get_elf_backend_data (abfd)->s->arch_size
> 
> elf16 is not a good idea. I think we must not mix the size of cpu
> address with the format of ELF files. The ELF file can be larger than
> 64K and we might need indexes larger than 16-bit.

When I say  ``elf16'', I was thinking of an elf object file that has 16
bit addresses.  I'm not sure what other consequences such a move would
have.

Is there any reason why s->arch_size isn't 16 in your case?

	Andrew
From ac131313@cygnus.com Sat Apr 01 00:00:00 2000
From: Andrew Cagney <ac131313@cygnus.com>
To: Jim Blandy <jimb@cygnus.com>
Cc: Stephane Carrez <Stephane.Carrez@worldnet.fr>, gdb-patches@sourceware.cygnus.com
Subject: Re: path for gdb/dwarf2read.c, support 16-bit targets in dwarf-2
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <38E06721.6D3A08CD@cygnus.com>
References: <38D4DCB0.88313CB2@worldnet.fr> <38D5B6E0.50FF6A5E@cygnus.com> <38D68C56.856CB00C@worldnet.fr> <38D74A9E.A85ED8EC@cygnus.com> <38D7E6BC.79543EBA@worldnet.fr> <npd7og40xc.fsf@zwingli.cygnus.com>
X-SW-Source: 2000-q1/msg01079.html
Content-length: 1991

Jim Blandy wrote:

> Or maybe I'm misunderstanding things.  Andrew, as the committer of
> this change, can you comment?

From something in '97, I'll try :-)

> Mon Dec 15 11:38:52 1997  Andrew Cagney  <cagney@b1.cygnus.com>
> 
>         * dwarf2read.c: From change proposed by Gavin Koch.
>         (address_significant_size): New static variable.
>         (dwarf2_build_psymtabs_hard): Check consistency between
>         `address_size' and `address_significant_size'.
>         (read_address): MASK out all but the significant bits, as
>         determined by `address_significant_size', of any addresses.
>         (elf-bfd.h): Include.
>         (dwarf2_build_psymtabs_hard): Set `address_significant_size'
>         according to the arch_size of the elf object file.

I believe it is for an embedded 64 bit mips target (o64?) that is using
64 bit addresses within an elf32 executable.  (but the addresses are
assumed to be 32bit sign extended).  Due to elf32, some debug info is 64
bits, but other (symbol table?) is only 32 bits.

The mask has two effects:

	o	it makes data from the two tables
		match.

	o	it gives the user a better experience:
			(gdb) x/i 0x800000200
			0x800000200 <start>: ldi $1, 0
			(gdb) print &start
			$1 = 0x800000200
		vs
			x/i 0xffffffff800000200
			0xffffffff800000200 <start>: ldi $1, 0
			(gdb) print &start
			$2 = 0xffffffff800000200
		at the cost of carrying around wrong
		information and complicating the target.

As for ``fixing'' it.
One part is deprecating that object file format and changing it to
elf64.  I believe that, at the time the above format was created, BFD
didn't support elf64.
Also on the list is getting GDB to provide the above experience without
having the internal structures lie (ie have symtab contain correct
information).  This is likely to be important any way as people are
starting to work on the problem of a single GDB being able to debug both
elf32 and elf64 binaries.

I think I've got this right :-/

	Andrew
From ac131313@cygnus.com Sat Apr 01 00:00:00 2000
From: Andrew Cagney <ac131313@cygnus.com>
To: GDB Patches <gdb-patches@sourceware.cygnus.com>
Subject: GDB 5 2000-03-29
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <38E17D2C.F7EB65B9@cygnus.com>
X-SW-Source: 2000-q1/msg01102.html
Content-length: 6421

Below is my updated TODO list for GDB 5.  I've also attatched the patch
I'm applying to TODO.  You can see the gory details in the sources.

Looking at it.  There are four ``must haves'' left.

For the watchpoint patches, if at least some have been addressed, I'd
like to put the rest off.

For Solaris/x86, what shape is it in?

The remainder look like must fix bugs.

	Andrew


GDB 5.0: Must have
------------------

These are things that have been identifed as must-have for this
release of GDB.

--

Watch point related patches (Eli Zaretskii, Michael Snyder, ???)

Eli writes: This doesn't include the watchpoint-related patches I sent
beginning with August or September, and mentioned them again three
weeks ago.  Here again are the pointers to the relevant messages:

Hardware breakpoints and watchpoints: patches
http://sourceware.cygnus.com/ml/gdb-patches/1999-q3/msg00173.html

Re: Hardware breakpoints and watchpoints: patches
http://sourceware.cygnus.com/ml/gdb-patches/1999-q3/msg00204.html

Re: Hardware breakpoints and watchpoints: patches
http://sourceware.cygnus.com/ml/gdb-patches/1999-q4/msg00200.html

Hardware watchpoints for bitfields
http://sourceware.cygnus.com/ml/gdb-patches/1999-q4/msg00201.html

--

Tom's speedups to GDB (Tom Tromey, Jim Blandy)

I believe that there was a late breaking fix that stopped a coredump.

http://sourceware.cygnus.com/ml/gdb-patches/2000-q1/msg00869.html

--

Solaris/x86 - which? (Nick Duffek, Peter Schauer, Michael Snyder?)

Nick D's working through patches from Michael Snyder and Peter S.

--


RFA: procfs.c: init_procfs_ops should set
procfs_ops.to_has_[all]_memory (Peter Schauer, Andrew Cagney?)

I am pretty sure that this is caused by some accidental deletion, but
procfs.c:init_procfs_ops no longer sets procfs_ops.to_has_memory and
procfs_ops.to_has_all_memory.

http://sourceware.cygnus.com/ml/gdb-patches/2000-q1/msg01057.html
Wed Mar 29 13:40:40 2000  Andrew Cagney  <cagney@b1.cygnus.com>

	* TODO: Update GDB 5 status.

Index: TODO
===================================================================
RCS file: /cvs/src/src/gdb/TODO,v
retrieving revision 1.2
diff -u -r1.2 TODO
--- TODO	2000/03/27 10:24:58	1.2
+++ TODO	2000/03/29 03:43:21
@@ -62,26 +62,18 @@
 
 --
 
-Texinfo broken/builds (Andrew Cagney, Stan Shebs)
 
-Cagney probably botched a fix to a botch.
+RFA: procfs.c: init_procfs_ops should set
+procfs_ops.to_has_[all]_memory (Peter Schauer, Andrew Cagney?)
 
---
+I am pretty sure that this is caused by some accidental deletion, but
+procfs.c:init_procfs_ops no longer sets procfs_ops.to_has_memory and
+procfs_ops.to_has_all_memory.
 
-x86 linux GDB and SIGALRM
- http://sourceware.cygnus.com/ml/gdb/2000-q1/msg00803.html
+ http://sourceware.cygnus.com/ml/gdb-patches/2000-q1/msg01057.html
 
 --
 
-RFA: breakpoint.c: Minor output fixes for hardware watchpoints
- http://sourceware.cygnus.com/ml/gdb-patches/2000-q1/msg00558.html
-
-During implementation of hardware watchpoints on Solaris, I noticed the
-following inconsistencies in breakpoint.c output between software and
-hardware breakpoints.
-
---
-
 GDB 5.0: Nice to have
 ---------------------
 
@@ -126,6 +118,12 @@
 The pascal support patches nave been added to the patch data base.  I
 [cagney] strongly suspect that they are better suited for 5.1.
 
+Indent -gnu ?
+ http://sourceware.cygnus.com/ml/gdb/2000-q1/msg00496.html
+
+2 pascal language patches inserted in database
+ http://sourceware.cygnus.com/ml/gdb/2000-q1/msg00521.html
+
 --
 
 Programs run under GDB have SIGCHLD masked.
@@ -198,6 +196,39 @@
 
 --
 
+x86 linux GDB and SIGALRM (???)
+ http://sourceware.cygnus.com/ml/gdb/2000-q1/msg00803.html
+
+--
+
+Migrate qfThreadInfo packet -> qThreadInfo. (Andrew Cagney)
+
+Add support for packet enable/disable commands with these thread
+packets.  General cleanup.
+
+[PATCH] Document the ThreadInfo remote protocol queries
+ http://sourceware.cygnus.com/ml/gdb-patches/2000-q1/msg00832.html
+
+[PATCH] "info threads" queries for remote.c
+ http://sourceware.cygnus.com/ml/gdb-patches/2000-q1/msg00831.html
+
+--
+
+MI documentation in GDB user guide. (Andrew Cagney, Elena Zannoni,
+Stan Shebs, anyone else?)
+
+> (Are there plans to make gdbmi.texi be part of the manual as well?)
+
+I'd like to see it go in there sooner rather than later too.  Otherwise
+you're introducing discrepancies between the manual and the documentation,
+and everybody is confused - witness the lack of doc for the tracing
+commands still, some two years after they were added...
+
+[PATCH] GDB command-line switches and annotations docs
+ http://sourceware.cygnus.com/ml/gdb-patches/2000-q1/msg00639.html
+
+--
+
 GDB 5.0: Won't have
 -------------------
 
@@ -232,6 +263,33 @@
 
 --
 
+Elimination of make_cleanup_func. (Andrew Cagney)
+
+make_cleanup_func elimination
+ http://sourceware.cygnus.com/ml/gdb-patches/2000-q1/msg00791.html
+ http://sourceware.cygnus.com/ml/gdb-patches/2000-q1/msg00814.html
+
+--
+
+Allow GDB to use installed regex.  Think about updating regex to more
+recent version (Andrew Cagney).
+
+Re: A new patch for regex
+ http://sourceware.cygnus.com/ml/gdb-patches/2000-q1/msg00635.html
+
+A patch for gnu-regex
+ http://sourceware.cygnus.com/ml/gdb/2000-q1/msg00568.html
+
+--
+
+ChangeLog.mi vs ChangeLog-mi (Andrew Cagney)
+Needs further debate.
+
+Re: [PATCH] Add change-log variables to more MI files
+ http://sourceware.cygnus.com/ml/gdb-patches/2000-q1/msg00811.html
+
+--
+
 GDB 5.0: Test results
 ---------------------
 
@@ -329,6 +387,30 @@
 
 General Wish List
 =================
+
+--
+
+GDBARCH cleanup (Andrew Cagney)
+
+The non-generated parts of gdbarch.{sh,h,c} should be separated out
+into gdbarch-utils.[hc] (Name ok).
+
+The ``info architecture'' command should be replaced with a fixed
+``set architecture'' (implemented using the command.c enum code).
+
+Document that gdbarch_init_ftype could easily fail because it didn't
+identify an architecture.
+
+--
+
+Check that GDB can handle all BFD architectures (Andrew Cagney)
+
+There should be a test that checks that BFD/GDB are in sync with
+regard to architecture changes.  Something like a test that first
+queries GDB for all supported architectures and then feeds each back
+to GDB..  Anyone interested in learning how to write tests?  :-)
+
+--
 
 This list is probably not up to date, and opinions vary about the
 importance or even desirability of some of the items.
From ac131313@cygnus.com Sat Apr 01 00:00:00 2000
From: Andrew Cagney <ac131313@cygnus.com>
To: GDB Discussion <gdb@sourceware.cygnus.com>, GDB Patches <gdb-patches@sourceware.cygnus.com>
Subject: Re: [MAINT] src/mmalloc maintainers
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <38B9BF29.19152928@cygnus.com>
References: <38B35300.41508CB6@cygnus.com>
X-SW-Source: 2000-q1/msg00388.html
Content-length: 4258

Andrew Cagney wrote:
> 
> Hello,
> 
> This directory is probably best described as one of GDB's forgotten
> siblings.  At present it isn't clear what the maintenance policy is.
> With that in mind I'd like to propose:
> 
>         GDB's host/native maintainers have implicit check-in
>         rights to the src/mmalloc tree.  If there isn't a
>         relevant host/native maintainer than the head maintainer
>         ends up with the problem :-)
> 
> I can't see anyone doing anything to that directory tree unless they are
> a native/host maintainer and then the only thing would be fixing
> configury problems.
> 
> I'm almost tempted to include target maintainers.  I suspect, however,
> that getting the native expert a chance to look things over would be
> safer.
> 
> thoughts?


FYI,  I've checked in the attatched.  It hopefully reflects this
proposal.

	Andrew
Index: gdb/ChangeLog
Mon Feb 28 10:58:45 2000  Andrew Cagney  <cagney@b1.cygnus.com>

	* MAINTAINERS: Mention mmalloc.  Expand Host/Native and
 	Target/Architecture maintainers descriptions.

Index: mmalloc/ChangeLog
Mon Feb 28 10:33:51 2000  Andrew Cagney  <cagney@b1.cygnus.com>

	* MAINTAINERS: New file.

Index: gdb/MAINTAINERS
===================================================================
RCS file: /cvs/src/src/gdb/MAINTAINERS,v
retrieving revision 1.11
diff -p -r1.11 MAINTAINERS
*** MAINTAINERS	2000/02/26 06:20:56	1.11
--- MAINTAINERS	2000/02/28 00:06:00
*************** available to step in if the first mainta
*** 21,29 ****
  reason.
  
  
! Target/Architecture: Generic ISA - Instruction Set Architecture -
! issues. API variants, CPU variants.  *-tdep.c.
  
  d10v target		Andrew Cagney		cagney@cygnus.com
  d30v target		Andrew Cagney		cagney@cygnus.com
  mips target		Andrew Cagney		cagney@cygnus.com
--- 21,32 ----
  reason.
  
  
! Target/Architecture:
  
+ Generic ISA (Instruction Set Architecture) issues, API variants, CPU
+ variants.  *-tdep.c. The Target/Architecture maintainer works with the
+ host maintainer when resolving build issues.
+ 
  d10v target		Andrew Cagney		cagney@cygnus.com
  d30v target		Andrew Cagney		cagney@cygnus.com
  mips target		Andrew Cagney		cagney@cygnus.com
*************** arm target		Fernando Nasser		fnasser@cyg
*** 36,47 ****
  m32r target		Michael Snyder		msnyder@cygnus.com
  IA-64 target		Kevin Buettner		kevinb@cygnus.com
  
  
! Host/Native: Target specific native support - typically shared
! libraries and quirks to procfs/ptrace/...  A native maintainer works
! with the arch and core maintainer when resolving more generic
! problems.
  
  hp testsuite (gdb.hp)	Jimmy Guo	 adl-debugger-wdb-merge-guru@cup.hp.com
  djgpp native		Eli Zaretskii		eliz@gnu.org
  			DJ Delorie		dj@cygnus.com
--- 39,55 ----
  m32r target		Michael Snyder		msnyder@cygnus.com
  IA-64 target		Kevin Buettner		kevinb@cygnus.com
  
+ 
+ Host/Native:
  
! The Native maintainer is responsible for target specific
! native support - typically shared libraries and quirks to
! procfs/ptrace/...  The Native maintainer works with the Arch and Core
! maintainers when resolving more generic problems.
  
+ The host maintainer ensures that gdb (including mmalloc) can be built
+ as a cross debugger on their platform.
+ 
  hp testsuite (gdb.hp)	Jimmy Guo	 adl-debugger-wdb-merge-guru@cup.hp.com
  djgpp native		Eli Zaretskii		eliz@gnu.org
  			DJ Delorie		dj@cygnus.com
*************** Misc:
*** 105,111 ****
  Web pages.		Jim Kingdon		kingdon@redhat.com
  			(anyone can edit; kingdon is just lead maintainer)
  Makefile.in, configure*	ALL
! 
  
  
  		Write After Approval
--- 113,119 ----
  Web pages.		Jim Kingdon		kingdon@redhat.com
  			(anyone can edit; kingdon is just lead maintainer)
  Makefile.in, configure*	ALL
! mmalloc			ALL Host maintainers
  
  
  		Write After Approval
Index: mmalloc/MAINTAINERS
===================================================================
RCS file: MAINTAINERS
diff -N MAINTAINERS
*** /dev/null	Tue May  5 13:32:27 1998
--- MAINTAINERS	Sun Feb 27 16:06:09 2000
***************
*** 0 ****
--- 1,5 ----
+ The mmalloc directory is maintained by the GDB group's Host
+ maintainers.
+ 
+ This code is in a maintain-only phase - only configury patches fixing
+ host compile problems are generally accepted.
From msnyder@cygnus.com Sat Apr 01 00:00:00 2000
From: Michael Snyder <msnyder@cygnus.com>
To: Scott Bambrough <scottb@netwinder.org>
Cc: Fernando Nasser <fnasser@redhat.com>, Kevin Buettner <kevinb@cygnus.com>, gdb-patches@sourceware.cygnus.com
Subject: Re: store_floating() and arm-tdep.c
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <38C7F23D.61AF@cygnus.com>
References: <1000229000345.ZM15006@ocotillo.lan> <38BCE46B.CD7889B5@cygnus.com> <1000302074643.ZM19182@ocotillo.lan> <38C7BF53.731F8CF6@redhat.com> <38C7C9A4.3566EC87@netwinder.org>
X-SW-Source: 2000-q1/msg00630.html
Content-length: 986

Scott Bambrough wrote:
> 
> Fernando Nasser wrote:
> 
> > Now that Kevin fixed store_floating() we can use it in arm-tdep.c (as
> > well as extract_floating).  The code in there works fine for remote
> > targets but Scott has reported it fails for native Linux-ARM.
> 
> I'll be looking into this today.  Don't worry about it.
> 
> > P.S.: I can run the test on remote ARM targets.  I will need someone to
> > volunteer running the tests on native as well?  Scott, I guess you are
> > the most appropriate "volunteer" :-)
> 
> I've been running tests on the ARM Linux target on a NetWinder regularly.  The
> results of the testsuite follow.  Most of the problems are due to no
> linuxthreads support and problems stepping in/out or backtracing in signal
> handlers.  I'll work at implementing support for these over time.  I was hoping
> to port the x86 work, but just haven't had the time.

Hmm, the new thread_db module should be pretty 
target-independent (correct me if I'm wrong).
From ac131313@cygnus.com Sat Apr 01 00:00:00 2000
From: Andrew Cagney <ac131313@cygnus.com>
To: GDB Discussion <gdb@sourceware.cygnus.com>, GDB Patches <gdb-patches@sourceware.cygnus.com>
Subject: [GDB-MAINT] Updated maintainer list
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <38A3A58E.CDB11CE9@cygnus.com>
X-SW-Source: 2000-q1/msg00122.html
Content-length: 3448

Hello maintainers,

Below is the current list of maintainers.  As such, you will all be
getting check-in rights (adminstration and time permitting).

Given the move to a public CVS repository now is probably a good time to
review your current maintenance responsibilities and decide if you wish
to continue them.  I'm not trying to scare you or anything :-) It's just
that this really is a big and dramatic change.

d10v target		Andrew Cagney		cagney at cygnus dot com
d30v target		Andrew Cagney		cagney at cygnus dot com
mips target		Andrew Cagney		cagney at cygnus dot com
mn10300 target		Andrew Cagney		cagney at cygnus dot com
powerpc target		Elena Zannoni		ezannoni at cygnus dot com
arm target		Jim Ingham		jingham at cygnus dot com
m32r target		Michael Snyder		msnyder at cygnus dot com
hp testsuite (gdb.hp)	Jimmy Guo adl-debugger-wdb-merge-guru at cup dot
hp dot com
djgpp native		DJ Delorie		dj at cygnus dot com
win32 host & native	Chris Faylor		cgf at cygnus dot com
x86 linux native	Jim Blandy		jimb at cygnus dot com
hurd native		Mark Kettenis		kettenis at wins.va.nl
macos host & native	Stan Shebs		shebs at apple dot com
hpux, hp pa native	Jeff Law		law at cygnus dot com
generic arch support	Andrew Cagney		cagney at cygnus dot com
target vector		Andrew Cagney		cagney at cygnus dot com
main (main.c, top.c)	Elena Zannoni		ezannoni at cygnus dot com
readline		Elena Zannoni		ezannoni at cygnus dot com
generic symtabs		Jim Blandy		jimb at cygnus dot com
dwarf readers		Jim Blandy		jimb at cygnus dot com
elf reader		Jim Blandy		jimb at cygnus dot com
stabs reader		Jim Blandy		jimb at cygnus dot com
tracing			Michael Snyder		msnyder at cygnus dot com
threads			Michael Snyder		msnyder at cygnus dot com
breakpoint.c		Michael Snyder		msnyder at cygnus dot com
language support	David Taylor		taylor at cygnus dot com
expression eval		David Taylor		taylor at cygnus dot com
defs.h			David Taylor		taylor at cygnus dot com
utils.c			David Taylor		taylor at cygnus dot com
Scheme support		Jim Blandy		jimb at cygnus dot com
svr4 shlibs (solib.c)	Jim Blandy		jimb at cygnus dot com
coff reader		Philippe De Muyter	phdm at macqel dot be
remote.c		Andrew Cagney		cagney at cygnus dot com
sds protocol		Stan Shebs		shebs at apple dot com
rdi/adp protocol	Stan Shebs		shebs at apple dot com
gdbserver		Stan Shebs		shebs at apple dot com
documentation	 	Stan Shebs		shebs at apple dot com
testsuite	 	Stan Shebs		shebs at apple dot com
command interpreter	Fernando Nasser		fnasser at cygnus dot com
gdbtk (c & tcl)		Jim Ingham		jingham at cygnus dot com
libgui (w/foundry, sn)	Jim Ingham		jingham at cygnus dot com


For what its worth, I've already received recommendations that:

  djgpp responsibility be transfered to Eli Zaretskii.  (Eli, I assume
this
	is ok with you. You were presented with glowing references :-)

  GNU/Linux/PPC responsibility go to Kevin Buettner.  Given Kevin's
currently
	frantically trying to get that code merged in I can't see any problems.
	(actually, all I can see are benefits :-).

  powerpc target be transfered to Kevin Buettner.  Here it's Elena
Zannoni,
	the current maintainer looking to pass on the reins.  I can't see
	problems as Kevin is already knee deep in the AIX ABI code that
	is just one of the three ABI's burried in rs6000-tdep.c.

I personaly would like to ask J.T. Conklin (jtc at redback dot com) to
step forward and (at least) accept check-in after aproval rights.

	enjoy,
		Andrew
From dima@Chg.RU Sat Apr 01 00:00:00 2000
From: Dmitry Sivachenko <dima@Chg.RU>
To: gdb-patches@sourceware.cygnus.com
Subject: small patch to gdb.texinfo
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <200001301823.VAA60148@netserv1.chg.ru>
X-SW-Source: 2000-q1/msg00051.html
Content-length: 5976

Hello again!
(I really don't what to spam your mailing list :)

This new small patch to revision 1.1.1.14 of gdb.texinfo, cosmetic changes
only.  Please apply it.

Thank you in advance,
--dima


PS: I don't sure about mapped symbol file name, please check it, I have no
support of it on my FreeBSD box...




--- gdb.texinfo.orig	Sun Jan 30 21:01:45 2000
+++ gdb.texinfo	Sun Jan 30 21:06:00 2000
@@ -225,9 +225,9 @@
 from anyone else.
 
 @node Contributors
-@unnumberedsec Contributors to GDB
+@unnumberedsec Contributors to @value{GDBN}
 
-Richard Stallman was the original author of GDB, and of many other
+Richard Stallman was the original author of @value{GDBN}, and of many other
 @sc{gnu} programs.  Many others have contributed to its development.
 This section attempts to credit major contributors.  One of the virtues
 of free software is that everyone is free to contribute to it; with
@@ -258,7 +258,7 @@
 Richard Stallman, assisted at various times by Peter TerMaat, Chris
 Hanson, and Richard Mlynarik, handled releases through 2.8.
 
-Michael Tiemann is the author of most of the @sc{gnu} C++ support in GDB,
+Michael Tiemann is the author of most of the @sc{gnu} C++ support in @value{GDBN},
 with significant additional contributions from Per Bothner.  James
 Clark wrote the @sc{gnu} C++ demangler.  Early work on C++ was by Peter
 TerMaat (who also did much general update work leading to release 3.0).
@@ -325,7 +325,7 @@
 
 Matsushita sponsored the support for the MN10200 and MN10300 processors.
 
-Fujitsu sponsored the support for SPARClite and FR30 processors
+Fujitsu sponsored the support for SPARClite and FR30 processors.
 
 Kung Hsu, Jeff Law, and Rick Sladkey added support for hardware
 watchpoints.
@@ -335,7 +335,7 @@
 Stu Grossman wrote gdbserver.
 
 Jim Kingdon, Peter Schauer, Ian Taylor, and Stu Grossman made
-nearly innumerable bug fixes and cleanups throughout GDB.
+nearly innumerable bug fixes and cleanups throughout @value{GDBN}.
 
 The following people at the Hewlett-Packard Company contributed
 support for the PA-RISC 2.0 architecture, HP-UX 10.20, 10.30, and 11.0
@@ -345,8 +345,8 @@
 Rehrauer, and Elena Zannoni.  Kim Haase provided HP-specific
 information in this manual.
 
-Cygnus Solutions has sponsored GDB maintenance and much of its
-development since 1991.  Cygnus engineers who have worked on GDB
+Cygnus Solutions has sponsored @value{GDBN} maintenance and much of its
+development since 1991.  Cygnus engineers who have worked on @value{GDBN}
 fulltime include Mark Alexander, Jim Blandy, Per Bothner, Kevin
 Buettner, Edith Epstein, Chris Faylor, Fred Fish, Martin Hunt, Jim
 Ingham, John Gilmore, Stu Grossman, Kung Hsu, Jim Kingdon, John Metzler,
@@ -695,7 +695,7 @@
 ``process'', and there is often no way to get a core dump.  @value{GDBN}
 will warn you if it is unable to attach or to read core dumps.
 
-You can run @code{gdb} without printing the front material, which describes
+You can run @code{@value{GDBP}} without printing the front material, which describes
 @value{GDBN}'s non-warranty, by specifying @code{-silent}:
 
 @smallexample
@@ -789,7 +789,7 @@
 system call, you can use this option 
 to have @value{GDBN} write the symbols from your
 program into a reusable file in the current directory.  If the program you are debugging is
-called @file{/tmp/fred}, the mapped symbol file is @file{./fred.syms}.
+called @file{/tmp/fred}, the mapped symbol file is @file{/tmp/fred.syms}.
 Future @value{GDBN} debugging sessions notice the presence of this file,
 and can quickly map in symbol information from it, rather than reading
 the symbol table from the executable program.
@@ -859,7 +859,7 @@
 @item -nowindows
 @itemx -nw
 ``No windows''.  If @value{GDBN} comes with a graphical user interface
-(GUI) built in, then this option tells GDB to only use the command-line
+(GUI) built in, then this option tells @value{GDBN} to only use the command-line
 interface.  If no GUI is available, this option has no effect.
 
 @item -windows
@@ -916,7 +916,7 @@
 @table @code
 @kindex quit @r{[}@var{expression}@r{]}
 @kindex q
-@item quit
+@item quit @r{[}@var{expression}@r{]}
 To exit @value{GDBN}, use the @code{quit} command (abbreviated @code{q}), or 
 type an end-of-file character (usually @kbd{C-d}).  If you do not supply 
 @var{expression}, @value{GDBN} will terminate normally; otherwise it will 
@@ -986,7 +986,7 @@
 arguments whose meaning depends on the command name.  For example, the
 command @code{step} accepts an argument which is the number of times to
 step, as in @samp{step 5}.  You can also use the @code{step} command
-with no arguments.  Some command names do not allow any arguments.
+with no arguments.  Some commands do not allow any arguments.
 
 @cindex abbreviation
 @value{GDBN} command names may always be truncated if that abbreviation is
@@ -1000,7 +1000,7 @@
 @cindex repeating commands
 @kindex RET
 A blank line as input to @value{GDBN} (typing just @key{RET}) means to
-repeat the previous command. Certain commands (for example, @code{run})
+repeat the previous command.  Certain commands (for example, @code{run})
 will not repeat this way; these are commands whose unintentional
 repetition might cause trouble and which you are unlikely to want to
 repeat.
@@ -1289,7 +1289,7 @@
 version of @value{GDBN} you are running; as @value{GDBN} evolves, new
 commands are introduced, and old ones may wither away.  Also, many
 system vendors ship variant versions of @value{GDBN}, and there are
-variant versions of @value{GDBN} in GNU/Linux distributions as well.
+variant versions of @value{GDBN} in @sc{gnu}/Linux distributions as well.
 The version number is the same as the one announced when you start
 @value{GDBN}.
 
@@ -1300,7 +1300,7 @@
 @kindex show warranty
 @item show warranty
 Display the @sc{gnu} ``NO WARRANTY'' statement, or a warranty,
-if your version of @value{GDB} comes with one.
+if your version of @value{GDBN} comes with one.
 
 @end table
 
From ezannoni@cygnus.com Sat Apr 01 00:00:00 2000
From: Elena Zannoni <ezannoni@cygnus.com>
To: Fernando Nasser <fnasser@cygnus.com>
Cc: David Whedon <davidw@gordian.com>, gdb-patches@sourceware.cygnus.com
Subject: Re: [REPOST #2] patch: command deprecator
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <14554.39919.562287.915864@kwikemart.cygnus.com>
References: <Pine.BSF.3.96.1000229114028.22997B-100000@ares.gordian.com> <38DA9AE8.64AF8635@cygnus.com>
X-SW-Source: 2000-q1/msg00951.html
Content-length: 432

Fernando Nasser writes:
 > Andrew,
 > 
 > I know that there are 3 new functions (and one test proc) in David's patch and it represents an added functionality, but
 > the changes are not so big.  Is there any chance that we could safely include those without his assignment?
 > 
 > David: Maybe you got it (the assignment to FSF) already?
 > 

I saw David's name in the last assignments mail form the FSF. So he's
all set. 

Elena



^ permalink raw reply	[flat|nested] 6+ messages in thread
[parent not found: <38D4DCB0.88313CB2@worldnet.fr>]
end of thread, other threads:[~2000-04-01  0:00 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2000-04-01  0:00 path for gdb/dwarf2read.c, support 16-bit targets in dwarf-2 Stephane Carrez
     [not found] ` <38BB5463.D6E5B75C@cygnus.com>
     [not found]   ` <38C0D9D9.70987863@worldnet.fr>
     [not found]     ` <38C225F3.9E236A55@cygnus.com>
2000-03-28  8:24       ` Jim Blandy
     [not found] <38D4DCB0.88313CB2@worldnet.fr>
     [not found] ` <38D5B6E0.50FF6A5E@cygnus.com>
     [not found]   ` <38D68C56.856CB00C@worldnet.fr>
2000-04-01  0:00     ` Andrew Cagney
     [not found]       ` <38D7E6BC.79543EBA@worldnet.fr>
2000-03-27 12:23         ` Jim Blandy
     [not found]           ` <38E06721.6D3A08CD@cygnus.com>
     [not found]             ` <npsnx91szl.fsf@zwingli.cygnus.com>
2000-04-01  0:00               ` Andrew Cagney
     [not found]         ` <npem8w42bg.fsf@zwingli.cygnus.com>
2000-04-01  0:00           ` Fernando Nasser

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox