Re: RFA: gdbarch_free

[Jim Blandy <jimb@cygnus.com>]

> > There are no uses for this yet, except in some code that's not ready
> > for release yet.
> > 
> > 2000-02-28  Jim Blandy  <jimb@redhat.com>
> > 
> >         * gdbarch.sh: Emit a definition and declaration for gdbarch_free,
> >         a companion to gdbarch_alloc, which allows a gdbarch init function
> >         to free partially-built gdbarch structures.
> >         * gdbarch.c, gdbarch.h: Regenerated.
> 
> Jim,
> 
> Can you expand a little.
> 
> >From memory, I figured that if an _initialize* function failed to create
> a gdbarch the process was somewhat hosed and calling internal_error()
> was probably the best thing to do.

Whenever one provides an allocation function, one should always
provide a corresponding free function --- it gives you more freedom in
the way you allocate the object.

Why I'm freeing a gdbarch structure isn't really anyone's business but
my own.  The contract of the init function is simply that it returns
null or a valid gdbarch; who knows how I might go about creating that
gdbarch.  I might build it myself, for all you know.

The real story:

gdbarch_update calls the initialization function and checks the return
value.  If it's zero, it says "gdbarch_update: Target rejected
architecture".  I have an architecture with several variants, and I
want to return zero when the variant (info.bfd_arch_info->mach)
doesn't match anything I recognize.

This situation could arise if someone adds support for a new variant
of my architecture, but hasn't updated GDB yet.

I could check for this earlier, before calling gdbarch_alloc, but I'd
like to avoid having two `if' structures that need to stay in sync.
From assign@gnu.org Wed Mar 01 09:03:00 2000
From: assignments <assign@gnu.org>
To: gdb-patches@sourceware.cygnus.com
Subject: GDB assigns/disclaims
Date: Wed, 01 Mar 2000 09:03:00 -0000
Message-id: <200003011702.MAA11121@delysid.gnu.org>
X-SW-Source: 2000-03/msg00007.html
Content-length: 985

The following disclaimers and/or assignments concerning GDB
have recently been added to the file copyright.list here at the 
Free Software Foundation.  If you have any questions or corrections,
please send them to my general work address, 3diff@gnu.org.
                                     Thanks!
                                     Brian Youmans
                                     Assignments Clerk

GDB     Yutaka Niibe    Japan 1967      2000-01-08
Assigns past and future changes (sh-stub.c).
gniibe@chroot.org

ANY BINUTILS GCC GDB GLIBC GUILE        Mitsubishi Research Institute, Inc.	2000-01-11
Disclaims changes to free software  and "operating system components" by
Yutaka Niibe, in the past and for the next 30 years.

GDB     Pierre Muller   France 1965     2000-02-11
Assigns past and future changes (pascal support).
muller@ics.u-strasbg.fr

GDB     Daniel Berlin   US ?    2000-02-11
Assigns past and future changes (beos-hat.[ch], beossolib.c).
dan@cgsoftware.com
From donnte@microsoft.com Wed Mar 01 09:28:00 2000
From: Donn Terry <donnte@microsoft.com>
To: 'Philippe De Muyter' <phdm@macqel.be>, ac131313@cygnus.com
Cc: ezannoni@cygnus.com, gdb-patches@sourceware.cygnus.com
Subject: RE: HAVE_POLL is not enough
Date: Wed, 01 Mar 2000 09:28:00 -0000
Message-id: <BB61526CDE70D2119D0F00805FBECA2F12A39A06@RED-MSG-55>
X-SW-Source: 2000-03/msg00008.html
Content-length: 3838

I'm in a similar boat, except that:

Only poll() works some places (/proc).
Only select() works other places (pty/tty).
(This is a consequence of a "step in the right
direction", but the 2d step hasn't happened yet.)

Writing the /proc stuff to dynamically switch would
be a pain (at best).

The test really belongs in configure, but lacking
that it probably belongs in the manually configured
header files.  (Something along the lines of
(for the default):
#ifdef HAVE_POLL
#define USE_POLL_ON_PROC
#define USE_POLL_ON_TTY
#else
#undef USE_POLL_ON_PROC
#undef USE_POLL_ON_TTY
#endif

For special cases (using mine as an example):
#undef USE_POLL_ON_TTY
#undef USE_POLL_ON_PROC // Just for error prevention
#define USE_POLL_ON_PROC

Donn Terry
Speaking only for myself, of course.

> -----Original Message-----
> From: Philippe De Muyter [ mailto:phdm@macqel.be ]
> Sent: None
> To: ac131313@cygnus.com
> Cc: ezannoni@cygnus.com; gdb-patches@sourceware.cygnus.com
> Subject: Re: HAVE_POLL is not enough
> 
> 
> First of all, sorry for the long delay for answers, but I am 
> really busy
> (and more) with my day-hours work.
> 
> > Elena Zannoni wrote:
> > > 
> > > Philippe De Muyter writes:
> > >  > With the gdb cvs tree of 2000-02-19, on 
> m68k-motorola-sys, configure
> > >  > correctly detect  that we have `poll', but gdb 
> incorrectly assumes that
> > >  > `poll' can be used to wait for `stdin'.  On 
> m68k-motorola-sysv, tty's
> > >  > are not stream-based and not `poll'able.  Should the 
> configure test
> > >  > be enhanced ? I don't think so if we need to run a 
> target program to check
> > >  > that, because it would fail if we cross-compile gdb, 
> but if it can be
> > >  > determined by other ways, like the presence of some 
> constants in some
> > >  > header files then I would agree.  We could also always 
> compile in the `poll'
> > >  > version if HAVE_POLL, but switch to the the fall-back 
> method at run time if
> > >  > poll fails with POLLNVAL.
> > >  >
> > > 
> > > Right now the decision on whether to run gdb with or 
> without the event
> > > loop is determined by the user as start up, and it is not detected
> > > neither by configure or at run time. The easiest thing to 
> do for now
> 
> I did not ask explicitly to start gdb with or without the 
> event-loop, and it
> tried automatically to use the event-loop.  I don't know why 
> but that seems
> to invalidate Elena's statement that `it is determined by the 
> user as start up'.
> 
> > > is probably tell the user what happened and switch to
> > > non-event-loop mode.  Maybe some configury work could be done to
> > > determine whether the tty's can be pollable, I am not 
> familiar with
> > > your system enough to know whether this is anything 
> feasible.  Sorry I
> > > cannot be of more help here.
> > > How about the 'target async' part, would that work?
> > 
> > As far as I know, this problem is still present.
> > 
> > Following on from Elena's comment.  Is there any known work 
> around or
> > other hack available?
> > 
> > If we get really desparate there is always the option of putting:
> > 
> > 	HOST_POLL_BROKEN
> > 
> > in
> > 
> > 	config/m68k/xm-m68kv4.h
> > 
> > :-( (And yes, I'm about to get really desperate).
> > 
> > Philippe, if GDB is forced to use select, does it work?
> 
> If we never use poll, and always use select if it is 
> available, I think
> we'll then have the inverse problem : platforms where some 
> channels are
> `poll'-able, but not `select'-able.
> 
> So, my idea is : at gdb startup, first poll the needed fd's 
> one by one with
> a null or small timeout, and if one is not `poll'-able, then 
> switch to `select'.
> I know that on m68k-motorola-sysv, `stdin' is `select'-able, 
> so this scheme
> would work.
> 
> Sorry, no time for a patch at the moment.
> 
> > 
> > 	Andrew
> > 
> 
From ezannoni@cygnus.com Wed Mar 01 11:37:00 2000
From: Elena Zannoni <ezannoni@cygnus.com>
To: "Philippe De Muyter" <phdm@macqel.be>
Cc: ac131313@cygnus.com (Andrew Cagney), ezannoni@cygnus.com, gdb-patches@sourceware.cygnus.com
Subject: Re: HAVE_POLL is not enough
Date: Wed, 01 Mar 2000 11:37:00 -0000
Message-id: <14525.29055.263209.524839@kwikemart.cygnus.com>
References: <38BCBC3F.56354ECB@cygnus.com> <200003011430.PAA03609@mail.macqel.be>
X-SW-Source: 2000-03/msg00009.html
Content-length: 3047

Philippe De Muyter writes:
 > First of all, sorry for the long delay for answers, but I am really busy
 > (and more) with my day-hours work.
 > 
 > > Elena Zannoni wrote:
 > > > 
 > > > Philippe De Muyter writes:
 > > >  > With the gdb cvs tree of 2000-02-19, on m68k-motorola-sys, configure
 > > >  > correctly detect  that we have `poll', but gdb incorrectly assumes that
 > > >  > `poll' can be used to wait for `stdin'.  On m68k-motorola-sysv, tty's
 > > >  > are not stream-based and not `poll'able.  Should the configure test
 > > >  > be enhanced ? I don't think so if we need to run a target program to check
 > > >  > that, because it would fail if we cross-compile gdb, but if it can be
 > > >  > determined by other ways, like the presence of some constants in some
 > > >  > header files then I would agree.  We could also always compile in the `poll'
 > > >  > version if HAVE_POLL, but switch to the the fall-back method at run time if
 > > >  > poll fails with POLLNVAL.
 > > >  >
 > > > 
 > > > Right now the decision on whether to run gdb with or without the event
 > > > loop is determined by the user as start up, and it is not detected
 > > > neither by configure or at run time. The easiest thing to do for now
 > 
 > I did not ask explicitly to start gdb with or without the event-loop, and it
 > tried automatically to use the event-loop.  I don't know why but that seems
 > to invalidate Elena's statement that `it is determined by the user as start up'.
 > 

Sorry, that was unclear, there is a --noasync switch you can start up
gdb with and that will not use the event loop, but the old command
loop. (assuming it hasn't suffered from bitrot). 

Elena

 > > > is probably tell the user what happened and switch to
 > > > non-event-loop mode.  Maybe some configury work could be done to
 > > > determine whether the tty's can be pollable, I am not familiar with
 > > > your system enough to know whether this is anything feasible.  Sorry I
 > > > cannot be of more help here.
 > > > How about the 'target async' part, would that work?
 > > 
 > > As far as I know, this problem is still present.
 > > 
 > > Following on from Elena's comment.  Is there any known work around or
 > > other hack available?
 > > 
 > > If we get really desparate there is always the option of putting:
 > > 
 > > 	HOST_POLL_BROKEN
 > > 
 > > in
 > > 
 > > 	config/m68k/xm-m68kv4.h
 > > 
 > > :-( (And yes, I'm about to get really desperate).
 > > 
 > > Philippe, if GDB is forced to use select, does it work?
 > 
 > If we never use poll, and always use select if it is available, I think
 > we'll then have the inverse problem : platforms where some channels are
 > `poll'-able, but not `select'-able.
 >
 > So, my idea is : at gdb startup, first poll the needed fd's one by one with
 > a null or small timeout, and if one is not `poll'-able, then switch to `select'.
 > I know that on m68k-motorola-sysv, `stdin' is `select'-able, so this scheme
 > would work.
 > 
 > Sorry, no time for a patch at the moment.
 > 
 > > 
 > > 	Andrew
 > > 
 > 
From ezannoni@cygnus.com Wed Mar 01 12:19:00 2000
From: Elena Zannoni <ezannoni@cygnus.com>
To: gdb-patches@sourceware.cygnus.com
Subject: PATCH committed: mi-cmd-disas.c
Date: Wed, 01 Mar 2000 12:19:00 -0000
Message-id: <14525.31581.437389.79600@kwikemart.cygnus.com>
X-SW-Source: 2000-03/msg00010.html
Content-length: 2303

FYI, I just committed this bit.

Elena

Index: ChangeLog-mi
===================================================================
RCS file: /cvs/src/src/gdb/mi/ChangeLog-mi,v
retrieving revision 1.3
diff -c -r1.3 ChangeLog-mi
*** ChangeLog-mi        2000/02/23 06:19:22     1.3
--- ChangeLog-mi        2000/03/01 20:17:12
***************
*** 1,3 ****
--- 1,9 ----
+ 2000-03-01  Elena Zannoni  <ezannoni@kwikemart.cygnus.com>
+ 
+       * mi-cmd-disas.c (mi_cmd_disassemble): Use
+       ui_out_field_core_addr() instead of print_address_numeric(), to
+       maintain consistency throughout MI.
+ 
  Wed Feb 23 17:09:39 2000  Andrew Cagney  <cagney@b1.cygnus.com>
  
        * mi-cmd-break.c, mi-cmd-disas.c, mi-cmd-stack.c, mi-cmd-var.c,
Index: mi-cmd-disas.c
===================================================================
RCS file: /cvs/src/src/gdb/mi/mi-cmd-disas.c,v
retrieving revision 1.3
diff -c -r1.3 mi-cmd-disas.c
*** mi-cmd-disas.c      2000/02/23 06:19:22     1.3
--- mi-cmd-disas.c      2000/03/01 20:17:12
***************
*** 418,425 ****
                    num_displayed++;
                }
              ui_out_list_begin (uiout, NULL);
!             print_address_numeric (pc, 1, stb->stream);
!             ui_out_field_stream (uiout, "address", stb);
  
              if (!build_address_symbolic (pc, 0, &name, &offset, &filename, &line, &unmapped))
                {
--- 418,424 ----
                    num_displayed++;
                }
              ui_out_list_begin (uiout, NULL);
!             ui_out_field_core_addr (uiout, "address", pc);
  
              if (!build_address_symbolic (pc, 0, &name, &offset, &filename, &line, &unmapped))
                {
***************
*** 467,474 ****
                num_displayed++;
            }
          ui_out_list_begin (uiout, NULL);
!         print_address_numeric (pc, 1, stb->stream);
!         ui_out_field_stream (uiout, "address", stb);
  
          if (!build_address_symbolic (pc, 0, &name, &offset, &filename, &line, &unmapped))
            {
--- 466,472 ----
                num_displayed++;
            }
          ui_out_list_begin (uiout, NULL);
!         ui_out_field_core_addr (uiout, "address", pc);
  
          if (!build_address_symbolic (pc, 0, &name, &offset, &filename, &line, &unmapped))
            {
From ac131313@cygnus.com Wed Mar 01 14:16:00 2000
From: Andrew Cagney <ac131313@cygnus.com>
To: GDB Discussion <gdb@sourceware.cygnus.com>, GDB Patches <gdb-patches@sourceware.cygnus.com>
Subject: [MAINT] Daniel Berlin is C++ language maintainer
Date: Wed, 01 Mar 2000 14:16:00 -0000
Message-id: <38BD967B.CD2AF9F8@cygnus.com>
X-SW-Source: 2000-03/msg00011.html
Content-length: 336

Hello,

I'm very pleased to announce that Daniel Berlin has agreed to take on
the responsibility of C++ language support within GDB.  As many are
probably aware, Dan's been contributing a flurry of patches that fix
numerous C++ problems for some time.

Nice day for it!

		Andrew

C++ language support	Daniel Berlin		dan@cgsoftware.com
From kettenis@wins.uva.nl Wed Mar 01 15:33:00 2000
From: Mark Kettenis <kettenis@wins.uva.nl>
To: jimb@cygnus.com
Cc: gdb-patches@sourceware.cygnus.com
Subject: [PATCH RFA] Linux/i386 signal trampoline code
Date: Wed, 01 Mar 2000 15:33:00 -0000
Message-id: <200003012333.e21NXDw01833@delius.kettenis.local>
X-SW-Source: 2000-03/msg00012.html
Content-length: 10858

Can I check this in?

[Jim, I've sent you this patch before, but I'd really like to get this
checked in, to get my hands free to do some generic i386 work (which
would also touch i386-tdep.c).  There is one tiny difference: I moved
LINUX_SIGCONTEXT_{PC,SP}_OFFSET from config/i386/tm-linux.h to
i386-tdep.c.  There is no point in having it in the header file since
it is only used by the code in i386-tdep.c]

It fixes one test in the test-suite that otherwise fails on Linux
2.2.15 with glibc 2.1.3.  I've discussed things with Ulrich Drepper,
and the library internels on which this patch depends are considered
stable.

Mark


2000-03-02  Mark Kettenis  <kettenis@gnu.org>

	Fix support for Linux/i386 signal trampolines.  The old approach
	didn't work for Linux 2.2 and beyond, and didn't work with recent
	versions of the GNU C library.
	* i386-tdep.c (LINUX_RT_SIGTRAMP_INSN0, LINUX_RT_SIGTRAMP_OFFSET0,
	LINUX_RT_SIGTRAMP_INSN1, LINUX_RT_SIGTRAMP_OFFSET1): New defines.
	(linux_rt_sigtramp_code): New variable.
	(LINUX_RT_SIGTRAMP_LEN): New define.
	(i386_linux_rt_sigtramp_start): New function.  Detect start of
	signal trampolines for RT signals.
	(i386_linux_sigtramp): Add support for RT signals.
	(i386_linux_sigcontext_addr): New function.
        (LINUX_SIGCONTEXT_PC_OFFSET, LINUX_SIGCONTEXT_SP_OFFSET):  New
	defines.  Moved here from config/i386/tm-linux.h.
	(i386_linux_sigtramp_saved_pc, i386_linux_sigtramp_saved_sp):
	Reimplement in terms of i386_linux_sigcontext_addr.
	* config/i386/tm-linux.h (LINUX_SIGCONTEXT_SIZE): Removed.
        (LINUX_SIGCONTEXT_PC_OFFSET, LINUX_SIGCONTEXT_SP_OFFSET):
        Moved to i386-tdep.c.
	(IN_SIGTRAMP): Recognize the names of the signal tranmpolines used
	by recent versions of the GNU C library.




Index: i386-tdep.c
===================================================================
RCS file: /cvs/src/src/gdb/i386-tdep.c,v
retrieving revision 1.4
diff -u -p -r1.4 i386-tdep.c
--- i386-tdep.c	2000/02/29 13:28:24	1.4
+++ i386-tdep.c	2000/03/01 23:23:46
@@ -781,11 +781,19 @@ i386v4_sigtramp_saved_pc (frame)
 
 #ifdef I386_LINUX_SIGTRAMP
 
-/* When the i386 Linux kernel calls a signal handler, the return
-   address points to a bit of code on the stack.  This function
-   returns whether the PC appears to be within this bit of code.
+/* Linux has two flavors of signals.  Normal signal handlers, and
+   "realtime" (RT) signals.  The RT signals can provide additional
+   information to the signal handler if the SA_SIGINFO flag is set
+   when establishing a signal handler using `sigaction'.  It is not
+   unlikely that future versions of Linux will support SA_SIGINFO for
+   normal signals too.  */
+
+/* When the i386 Linux kernel calls a signal handler and the
+   SA_RESTORER flag isn't set, the return address points to a bit of
+   code on the stack.  This function returns whether the PC appears to
+   be within this bit of code.
 
-   The instruction sequence is
+   The instruction sequence for normal signals is
        pop    %eax
        mov    $0x77,%eax
        int    $0x80
@@ -799,8 +807,16 @@ i386v4_sigtramp_saved_pc (frame)
    order to identify a signal trampoline, but there doesn't seem to be
    any other way.  The IN_SIGTRAMP macro in tm-linux.h arranges to
    only call us if no function name could be identified, which should
-   be the case since the code is on the stack.  */
+   be the case since the code is on the stack.
 
+   Detection of signal trampolines for handlers that set the
+   SA_RESTORER flag is in general not possible.  Unfortunately this is
+   what the GNU C Library has been doing for quite some time now.
+   However, as of version 2.1.2, the GNU C Library uses signal
+   trampolines (named __restore and __restore_rt) that are identical
+   to the ones used by the kernel.  Therefore, these trampolines are
+   supported too.  */
+
 #define LINUX_SIGTRAMP_INSN0 (0x58)	/* pop %eax */
 #define LINUX_SIGTRAMP_OFFSET0 (0)
 #define LINUX_SIGTRAMP_INSN1 (0xb8)	/* mov $NNNN,%eax */
@@ -864,51 +880,151 @@ i386_linux_sigtramp_start (pc)
   return pc;
 }
 
+/* This function does the same for RT signals.  Here the instruction
+   sequence is
+       mov    $0xad,%eax
+       int    $0x80
+   or 0xb8 0xad 0x00 0x00 0x00 0xcd 0x80.
+
+   The effect is to call the system call rt_sigreturn.  */
+
+#define LINUX_RT_SIGTRAMP_INSN0 (0xb8)	/* mov $NNNN,%eax */
+#define LINUX_RT_SIGTRAMP_OFFSET0 (0)
+#define LINUX_RT_SIGTRAMP_INSN1 (0xcd)	/* int */
+#define LINUX_RT_SIGTRAMP_OFFSET1 (5)
+
+static const unsigned char linux_rt_sigtramp_code[] =
+{
+  LINUX_RT_SIGTRAMP_INSN0, 0xad, 0x00, 0x00, 0x00,	/* mov $0xad,%eax */
+  LINUX_RT_SIGTRAMP_INSN1, 0x80				/* int $0x80 */
+};
+
+#define LINUX_RT_SIGTRAMP_LEN (sizeof linux_rt_sigtramp_code)
+
+/* If PC is in a RT sigtramp routine, return the address of the start
+   of the routine.  Otherwise, return 0.  */
+
+static CORE_ADDR
+i386_linux_rt_sigtramp_start (pc)
+     CORE_ADDR pc;
+{
+  unsigned char buf[LINUX_RT_SIGTRAMP_LEN];
+
+  /* We only recognize a signal trampoline if PC is at the start of
+     one of the two instructions.  We optimize for finding the PC at
+     the start, as will be the case when the trampoline is not the
+     first frame on the stack.  We assume that in the case where the
+     PC is not at the start of the instruction sequence, there will be
+     a few trailing readable bytes on the stack.  */
+
+  if (read_memory_nobpt (pc, (char *) buf, LINUX_RT_SIGTRAMP_LEN) != 0)
+    return 0;
+
+  if (buf[0] != LINUX_RT_SIGTRAMP_INSN0)
+    {
+      if (buf[0] != LINUX_RT_SIGTRAMP_INSN1)
+	return 0;
+
+      pc -= LINUX_RT_SIGTRAMP_OFFSET1;
+
+      if (read_memory_nobpt (pc, (char *) buf, LINUX_RT_SIGTRAMP_LEN) != 0)
+	return 0;
+    }
+
+  if (memcmp (buf, linux_rt_sigtramp_code, LINUX_RT_SIGTRAMP_LEN) != 0)
+    return 0;
+
+  return pc;
+}
+
 /* Return whether PC is in a Linux sigtramp routine.  */
 
 int
 i386_linux_sigtramp (pc)
      CORE_ADDR pc;
 {
-  return i386_linux_sigtramp_start (pc) != 0;
+  return (i386_linux_sigtramp_start (pc) != 0
+	  || i386_linux_rt_sigtramp_start (pc) != 0);
 }
 
-/* Assuming FRAME is for a Linux sigtramp routine, return the saved
-   program counter.  The Linux kernel will set up a sigcontext
-   structure immediately before the sigtramp routine on the stack.  */
+/* Assuming FRAME is for a Linux sigtramp routine, return the address
+   of the associated sigcontext structure.  */
 
 CORE_ADDR
-i386_linux_sigtramp_saved_pc (frame)
+i386_linux_sigcontext_addr (frame)
      struct frame_info *frame;
 {
   CORE_ADDR pc;
 
   pc = i386_linux_sigtramp_start (frame->pc);
-  if (pc == 0)
-    error ("i386_linux_sigtramp_saved_pc called when no sigtramp");
-  return read_memory_integer ((pc
-			       - LINUX_SIGCONTEXT_SIZE
-			       + LINUX_SIGCONTEXT_PC_OFFSET),
-			      4);
+  if (pc)
+    {
+      CORE_ADDR sp;
+
+      if (frame->next)
+	/* If this isn't the top frame, it must be the frame for the
+	   signal handler itself.  The sigcontext structure lives on
+	   the stack, right after the signum argument.  */
+	return frame->next->frame + 12;
+
+      /* This is the top frame.  We'll have to find the address of the
+	 sigcontext structure by looking at the stack pointer.  Keep
+	 in mind that the first instruction of the sigtramp code is
+	 "pop %eax".  If the PC is at this instruction, adjust the
+	 returned value accordingly.  */
+      sp = read_register (SP_REGNUM);
+      if (pc == frame->pc)
+	return sp + 4;
+      return sp;
+    }
+
+  pc = i386_linux_rt_sigtramp_start (frame->pc);
+  if (pc)
+    {
+      if (frame->next)
+	/* If this isn't the top frame, it must be the frame for the
+	   signal handler itself.  The sigcontext structure is part of
+	   the user context.  A pointer to the user context is passed
+	   as the third argument to the signal handler.  */
+	return read_memory_integer (frame->next->frame + 16, 4) + 20;
+
+      /* This is the top frame.  Again, use the stack pointer to find
+	 the address of the sigcontext structure.  */
+      return read_memory_integer (read_register (SP_REGNUM) + 8, 4) + 20;
+    }
+
+  error ("Couldn't recognize signal trampoline.");
+  return 0;
 }
 
+/* Offset to saved PC in sigcontext, from <asm/sigcontext.h>.  */
+#define LINUX_SIGCONTEXT_PC_OFFSET (56)
+
 /* Assuming FRAME is for a Linux sigtramp routine, return the saved
-   stack pointer.  The Linux kernel will set up a sigcontext structure
-   immediately before the sigtramp routine on the stack.  */
+   program counter.  */
 
 CORE_ADDR
-i386_linux_sigtramp_saved_sp (frame)
+i386_linux_sigtramp_saved_pc (frame)
      struct frame_info *frame;
 {
-  CORE_ADDR pc;
+  CORE_ADDR addr;
+  addr = i386_linux_sigcontext_addr (frame);
+  return read_memory_integer (addr + LINUX_SIGCONTEXT_PC_OFFSET, 4);
+}
 
-  pc = i386_linux_sigtramp_start (frame->pc);
-  if (pc == 0)
-    error ("i386_linux_sigtramp_saved_sp called when no sigtramp");
-  return read_memory_integer ((pc
-			       - LINUX_SIGCONTEXT_SIZE
-			       + LINUX_SIGCONTEXT_SP_OFFSET),
-			      4);
+/* Offset to saved SP in sigcontext, from <asm/sigcontext.h>.  */
+#define LINUX_SIGCONTEXT_SP_OFFSET (28)
+
+/* Assuming FRAME is for a Linux sigtramp routine, return the saved
+   stack pointer.  */
+
+CORE_ADDR
+i386_linux_sigtramp_saved_sp (frame)
+     struct frame_info *frame;
+{
+  CORE_ADDR addr;
+  addr = i386_linux_sigcontext_addr (frame);
+  return read_memory_integer (addr + LINUX_SIGCONTEXT_SP_OFFSET, 4);
 }
 
 #endif /* I386_LINUX_SIGTRAMP */
Index: config/i386/tm-linux.h
===================================================================
RCS file: /cvs/src/src/gdb/config/i386/tm-linux.h,v
retrieving revision 1.1.1.8
diff -u -p -r1.1.1.8 tm-linux.h
--- config/i386/tm-linux.h	1999/12/07 03:56:10	1.1.1.8
+++ config/i386/tm-linux.h	2000/03/01 23:23:46
@@ -30,15 +30,6 @@
 #include "i386/tm-i386.h"
 #include "tm-linux.h"
 
-/* Size of sigcontext, from <asm/sigcontext.h>.  */
-#define LINUX_SIGCONTEXT_SIZE (88)
-
-/* Offset to saved PC in sigcontext, from <asm/sigcontext.h>.  */
-#define LINUX_SIGCONTEXT_PC_OFFSET (56)
-
-/* Offset to saved SP in sigcontext, from <asm/sigcontext.h>.  */
-#define LINUX_SIGCONTEXT_SP_OFFSET (28)
-
 #define LOW_RETURN_REGNUM 0	/* holds low four bytes of result */
 #define HIGH_RETURN_REGNUM 2	/* holds high four bytes of result */
 
@@ -108,7 +99,9 @@ extern int i387_store_floating   (PTR ad
    order to support backtracing through calls to signal handlers.  */
 
 #define I386_LINUX_SIGTRAMP
-#define IN_SIGTRAMP(pc, name) ((name) == NULL && i386_linux_sigtramp (pc))
+#define IN_SIGTRAMP(pc, name)                                           \
+  ((name) ? (STREQ ("__restore", name) || STREQ ("__restore_rt", name)) \
+          : i386_linux_sigtramp (pc))
 
 extern int i386_linux_sigtramp PARAMS ((CORE_ADDR));
 
From kettenis@wins.uva.nl Wed Mar 01 15:40:00 2000
From: Mark Kettenis <kettenis@wins.uva.nl>
To: ac131313@cygnus.com
Cc: gdb@sourceware.cygnus.com, gdb-patches@sourceware.cygnus.com
Subject: Re: [MAINT] x86 maintainers .....
Date: Wed, 01 Mar 2000 15:40:00 -0000
Message-id: <200003012340.e21Ne6o00157@delius.kettenis.local>
References: <38BCA2B9.3BDE66AD@cygnus.com>
X-SW-Source: 2000-03/msg00013.html
Content-length: 406

   Date: Wed, 01 Mar 2000 15:55:21 +1100
   From: Andrew Cagney <ac131313@cygnus.com>

   Hello,

   I'd like to put forward the following:


   x86 target		Mark Kettenis		kettenis@gnu.org

   GNU/Linux/x86 native & host
			   Jim Blandy		jimb@cygnus.com
			   Mark Kettenis		kettenis@gnu.org


No problems with those.  I'll start working on those once you've added
them to the MAINTAINERS file :-).

Mark
From ac131313@cygnus.com Wed Mar 01 21:00:00 2000
From: Andrew Cagney <ac131313@cygnus.com>
To: GDB Discussion <gdb@sourceware.cygnus.com>
Cc: GDB Patches <gdb-patches@sourceware.cygnus.com>
Subject: [MAINT] Peter Schauer and Michael Snyder for ``Blanket Write'' maintainers
Date: Wed, 01 Mar 2000 21:00:00 -0000
Message-id: <38BDF545.34DB6172@cygnus.com>
X-SW-Source: 2000-03/msg00014.html
Content-length: 454

Hello,

I'd like to put forward that both:

    Michael Snyder          msnyder@cygnus.com
    Peter Schauer          
Peter.Schauer@regent.e-technik.tu-muenchen.de

be added to the ``Blanket Write Privs'' maintainers list.

Michael Snyder has been hacking continuously on GDB since at least '96
and stands as Red Hat's most experienced GDB developer.  In Peter
Shauer, case he has been working on improving GDB for much longer (the
early '90).

	Andrew
From kingdon@redhat.com Wed Mar 01 21:52:00 2000
From: Jim Kingdon <kingdon@redhat.com>
To: ac131313@cygnus.com
Cc: gdb-patches@sourceware.cygnus.com, blizzard@mozilla.org
Subject: Re: dlclose()
Date: Wed, 01 Mar 2000 21:52:00 -0000
Message-id: <200003020552.AAA07061@devserv.devel.redhat.com>
References: <200002161953.OAA07411@devserv.devel.redhat.com> <38BD058E.51313D7D@cygnus.com>
X-SW-Source: 2000-03/msg00015.html
Content-length: 5974

> One fix, and some extra random noise:

OK, I've changed assert() to internal_error() and reworded the
comment.  PTR is also gone.

I don't know how the WITHDRAWN thing is supposed to work, but this
patch supercedes the two that I already posted under the subject line
"dlclose()".

> JimB's got the final say.

Well, any reactions, JimB?  We don't have any other solib.c
maintainers yet.  I also haven't heard from Mark Kettenis recently on
this issue - I know he was talking about an solib.c rewrite (not
something I disagree with, really), but that was in the context of a
rather different patch (even if it addressed the same problem).

2000-02-20  Jim Kingdon  <kingdon@redhat.com>

	* solib.c (find_solib): New argument recheck.
	* solib.c (solib_add): Pass it as 1, and add logic to delete
	shared libraries which aren't still in the inferior.
	(struct so_list): New field found_me, for solib_add.
	* solib.c (other find_solib callers): Pass recheck as 0.

Index: solib.c
===================================================================
RCS file: /cvs/src/src/gdb/solib.c,v
retrieving revision 1.1.1.10
diff -u -r1.1.1.10 solib.c
--- solib.c	1999/11/17 02:30:28	1.1.1.10
+++ solib.c	2000/03/02 05:19:21
@@ -143,6 +143,11 @@
     char so_name[MAX_PATH_SIZE];	/* shared object lib name (FIXME) */
     char symbols_loaded;	/* flag: symbols read in yet? */
     char from_tty;		/* flag: print msgs? */
+
+    /* Flag for use within solib_add: have we seen this library actually
+       still mapped in the inferior this pass?  */
+    char found_me;
+
     struct objfile *objfile;	/* objfile for loaded lib */
     struct section_table *sections;
     struct section_table *sections_end;
@@ -181,8 +186,7 @@
 
 static int symbol_add_stub PARAMS ((PTR));
 
-static struct so_list *
-  find_solib PARAMS ((struct so_list *));
+static struct so_list *find_solib (struct so_list *, int);
 
 static struct link_map *
   first_link_map_member PARAMS ((void));
@@ -975,8 +979,10 @@
  */
 
 static struct so_list *
-find_solib (so_list_ptr)
-     struct so_list *so_list_ptr;	/* Last lm or NULL for first one */
+find_solib (struct so_list *so_list_ptr,
+	    /* Nonzero if we should read all the entries from the inferior,
+	       not just the ones at the end of the list.  */
+	    int recheck)
 {
   struct so_list *so_list_next = NULL;
   struct link_map *lm = NULL;
@@ -985,7 +991,9 @@
   if (so_list_ptr == NULL)
     {
       /* We are setting up for a new scan through the loaded images. */
-      if ((so_list_next = so_list_head) == NULL)
+      so_list_next = so_list_head;
+      if (so_list_next == NULL
+	  || recheck)
 	{
 	  /* We have not already read in the dynamic linking structures
 	     from the inferior, lookup the address of the base structure. */
@@ -1002,7 +1010,8 @@
     {
       /* We have been called before, and are in the process of walking
          the shared library list.  Advance to the next shared object. */
-      if ((lm = LM_NEXT (so_list_ptr)) == NULL)
+      lm = LM_NEXT (so_list_ptr);
+      if (recheck || lm == NULL)
 	{
 	  /* We have hit the end of the list, so check to see if any were
 	     added, but be quiet if we can't read from the target any more. */
@@ -1020,7 +1029,7 @@
 	}
       so_list_next = so_list_ptr->next;
     }
-  if ((so_list_next == NULL) && (lm != NULL))
+  if ((so_list_next == NULL || recheck) && (lm != NULL))
     {
       /* Get next link map structure from inferior image and build a local
          abbreviated load_map structure */
@@ -1188,7 +1197,7 @@
       /* Count how many new section_table entries there are.  */
       so = NULL;
       count = 0;
-      while ((so = find_solib (so)) != NULL)
+      while ((so = find_solib (so, 0)) != NULL)
 	{
 	  if (so->so_name[0] && !match_main (so->so_name))
 	    {
@@ -1201,7 +1210,7 @@
 	  
 	  /* Add these section table entries to the target's table.  */
 	  old = target_resize_to_sections (target, count);
-	  while ((so = find_solib (so)) != NULL)
+	  while ((so = find_solib (so, 0)) != NULL)
 	    {
 	      if (so->so_name[0])
 		{
@@ -1215,9 +1224,13 @@
 	}
     }
 
+  for (so = so_list_head; so != NULL; so = so->next)
+    so->found_me = 0;
+
   /* Now add the symbol files.  */
-  while ((so = find_solib (so)) != NULL)
+  while ((so = find_solib (so, 1)) != NULL)
     {
+      so->found_me = 1;
       if (so->so_name[0] && re_exec (so->so_name) &&
 	  !match_main (so->so_name))
 	{
@@ -1240,6 +1253,44 @@
 	}
     }
 
+  {
+    struct so_list *prev;
+    prev = NULL;
+    for (so = so_list_head; so != NULL; so = so->next)
+      {
+	if (!so->found_me)
+	  {
+	    /* If there were an analogue to
+	       disable_breakpoints_in_shlibs but just for this one
+	       struct so_list, we'd call it.  */
+
+	    if (so->sections != NULL)
+	      free (so->sections);
+
+	    free_objfile (so->objfile);
+
+	    /* Punt the issue of the section tables that we put in the
+	       target vector.  The excuse is that they are basically
+	       used for coredumps rather than running programs, and
+	       with coredumps we don't unload shared libraries.  */
+
+	    if (so->abfd == NULL)
+	      internal_error ("no bfd in solib_add");
+	    if (!bfd_close (so->abfd))
+	      warning ("cannot close \"%s\": %s",
+		       so->so_name, bfd_errmsg (bfd_get_error ()));
+
+	    if (prev == NULL)
+	      so_list_head = so->next;
+	    else
+	      prev->next = so->next;
+
+	    free (so);
+	  }
+	prev = so;
+      }
+  }
+
   /* Getting new symbols may change our opinion about what is
      frameless.  */
   if (so_last)
@@ -1289,7 +1340,7 @@
   addr_fmt = "016l";
 #endif
 
-  while ((so = find_solib (so)) != NULL)
+  while ((so = find_solib (so, 0)) != NULL)
     {
       if (so->so_name[0])
 	{
@@ -1347,7 +1398,7 @@
 {
   register struct so_list *so = 0;	/* link map state variable */
 
-  while ((so = find_solib (so)) != NULL)
+  while ((so = find_solib (so, 0)) != NULL)
     {
       if (so->so_name[0])
 	{
From kingdon@redhat.com Wed Mar 01 22:00:00 2000
From: Jim Kingdon <kingdon@redhat.com>
To: gdb-patches@sourceware.cygnus.com
Subject: Re: [MAINT] Minor admin tweeks
Date: Wed, 01 Mar 2000 22:00:00 -0000
Message-id: <b900153hd.fsf@rtl.cygnus.com>
References: <38BC6514.DC70948@cygnus.com>
X-SW-Source: 2000-03/msg00016.html
Content-length: 361

	* MAINTAINERS: Document people with paperwork pending.

Sorry, I'm a bit confused by this one.  Did you mean "+" rather than
"*" for the people you added the symbol to ("*" means that they don't
have an account, according to the key)?

Philippe De Muyter seems to have the right listing in copyright.html
(1996-06-12).  As does JT Conklin (1998-12-21).
From ac131313@cygnus.com Wed Mar 01 22:22:00 2000
From: Andrew Cagney <ac131313@cygnus.com>
To: Jim Kingdon <kingdon@redhat.com>
Cc: gdb-patches@sourceware.cygnus.com, blizzard@mozilla.org
Subject: Re: dlclose()
Date: Wed, 01 Mar 2000 22:22:00 -0000
Message-id: <38BE083D.9F600CA6@cygnus.com>
References: <200002161953.OAA07411@devserv.devel.redhat.com> <38BD058E.51313D7D@cygnus.com> <200003020552.AAA07061@devserv.devel.redhat.com>
X-SW-Source: 2000-03/msg00017.html
Content-length: 864

Jim Kingdon wrote:
> 
> > One fix, and some extra random noise:
> 
> OK, I've changed assert() to internal_error() and reworded the
> comment.  PTR is also gone.
> 
> I don't know how the WITHDRAWN thing is supposed to work, but this
> patch supercedes the two that I already posted under the subject line
> "dlclose()".
> 
> > JimB's got the final say.

> I don't know how the WITHDRAWN thing is supposed to work, but this
> patch supercedes the two that I already posted under the subject line
> "dlclose()".

Sorry, I've probably confused everyone.

It's when someone realizes that their patch is completely stuffed (you
can find examples of me doing this on the binutils mailing list :-) and
want to either drop it or rewrite it.  Posting a note saying hey I'm
withdrawing this patch gives the discussion closure.

You're doing none of this,

	sorry,
		Andrew
From ac131313@cygnus.com Wed Mar 01 22:29:00 2000
From: Andrew Cagney <ac131313@cygnus.com>
To: Jim Kingdon <kingdon@redhat.com>
Cc: gdb-patches@sourceware.cygnus.com
Subject: Re: [MAINT] Minor admin tweeks
Date: Wed, 01 Mar 2000 22:29:00 -0000
Message-id: <38BE0A0E.ED3A565B@cygnus.com>
References: <38BC6514.DC70948@cygnus.com> <b900153hd.fsf@rtl.cygnus.com>
X-SW-Source: 2000-03/msg00018.html
Content-length: 769

Jim Kingdon wrote:
> 
>         * MAINTAINERS: Document people with paperwork pending.
> 
> Sorry, I'm a bit confused by this one.  Did you mean "+" rather than
> "*" for the people you added the symbol to ("*" means that they don't
> have an account, according to the key)?
> 
> Philippe De Muyter seems to have the right listing in copyright.html
> (1996-06-12).  As does JT Conklin (1998-12-21).

The ChangeLog entry (poorly worded) in combination with the file changes
have thrown a few people.
As you note, the footnotes are:

	* Indicates folks we need to get
	  Kerberos/ssh accounts ready so they
	  can write in the source tree

	+ Indicates folks that have been caught up in a paper trail.
	
I was refering to the ``account request form'' paperwork.

	Andrew
From kevinb@cygnus.com Wed Mar 01 23:47:00 2000
From: Kevin Buettner <kevinb@cygnus.com>
To: gdb-patches@sourceware.cygnus.com
Subject: Re: [PATCH RFA] store_floating(), extract_floating() fixes
Date: Wed, 01 Mar 2000 23:47:00 -0000
Message-id: <1000302074643.ZM19182@ocotillo.lan>
References: <1000229000345.ZM15006@ocotillo.lan> <38BCE46B.CD7889B5@cygnus.com> <ac131313@cygnus.com>
X-SW-Source: 2000-03/msg00019.html
Content-length: 218

On Mar 1,  8:35pm, Andrew Cagney wrote:

> >         * findvar.c (extract_floating, store_floating): Use target
> >         floating point type sizes rather host sizes to determine
[...]
> Approved.

Committed.

Kevin
From kettenis@wins.uva.nl Thu Mar 02 07:52:00 2000
From: Mark Kettenis <kettenis@wins.uva.nl>
To: gdb-patches@sourceware.cygnus.com
Subject: [PATCH] AIX/i386 config tweaks
Date: Thu, 02 Mar 2000 07:52:00 -0000
Message-id: <200003021552.e22FqXZ09797@delius.kettenis.local>
X-SW-Source: 2000-03/msg00020.html
Content-length: 2936

FYI, I have checked in the following.

This is untested, but AIX/i386 was broken anyway, and in theory this
should fix it.  The problem is that
i386-tdep.c:i386_extract_return_value() accessed the FP0_REGNUM in
GDB's register array, but since the reorganization of tm-i386.h last
fall, the register array wasn't large enough anymore.

It also clears the way for some changes I'm planning to make to
i386-tdep.c:i386_extract_return_value().

Mark


2000-03-02  Mark Kettenis  <kettenis@gnu.org>

	* config/i386/tm-i386aix.h (NUM_FPREGS, NUM_REGS, REGISTER_BYTES):
	Override definitions to include the normal FPU registers.
	(REGISTER_CONVERTIBLE, REGISTER_CONVERT_TO_VIRTUAL,
	REGISTER_CONVERT_TO_RAW): Removed.  The default definitions are
	fine for AIX/i386.
	(i387_to_double, double_to_i387): Remove prototypes.


Index: config/i386/tm-i386aix.h
===================================================================
RCS file: /cvs/src/src/gdb/config/i386/tm-i386aix.h,v
retrieving revision 1.1.1.2
diff -u -p -r1.1.1.2 tm-i386aix.h
--- config/i386/tm-i386aix.h	1999/07/07 20:13:03	1.1.1.2
+++ config/i386/tm-i386aix.h	2000/03/02 15:37:29
@@ -29,40 +29,27 @@
 #ifndef I386
 #define I386 1
 #endif
+
+/* FIXME: kettenis/2000-03-02: This is used in
+   i386-tdep.c:i386_extract_return_value(), and will be remove once
+   I've fixed that.  Meanwhile don't use it for any other purpose
+   please!  */
 #ifndef I386_AIX_TARGET
 #define I386_AIX_TARGET 1
 #endif
-
-/* Nonzero if register N requires conversion
-   from raw format to virtual format.  */
-
-#undef  REGISTER_CONVERTIBLE
-#define REGISTER_CONVERTIBLE(N) \
-  ((N < FP0_REGNUM) ? 0 : 1)
-
-/* Convert data from raw format for register REGNUM in buffer FROM
-   to virtual format with type TYPE in buffer TO.  */
 
-#undef REGISTER_CONVERT_TO_VIRTUAL
-#define REGISTER_CONVERT_TO_VIRTUAL(REGNUM,TYPE,FROM,TO) \
-{ \
-  double val; \
-  i387_to_double ((FROM), (char *)&val); \
-  store_floating ((TO), TYPE_LENGTH (TYPE), val); \
-}
-extern void
-i387_to_double PARAMS ((char *, char *));
+/* AIX/i386 has FPU support.  However, the native configuration (which
+   is the only supported configuration) doesn't make the FPU control
+   registers available.  Override the appropriate symbols such that
+   only the normal FPU registers are included in GDB's register array.  */
+   
+#undef NUM_FPREGS
+#define NUM_FPREGS (8)
 
-/* Convert data from virtual format with type TYPE in buffer FROM
-   to raw format for register REGNUM in buffer TO.  */
+#undef NUM_REGS
+#define NUM_REGS (NUM_GREGS + NUM_FPREGS)
 
-#undef REGISTER_CONVERT_TO_RAW
-#define REGISTER_CONVERT_TO_RAW(TYPE,REGNUM,FROM,TO) \
-{ \
-  double val = extract_floating ((FROM), TYPE_LENGTH (TYPE)); \
-  double_to_i387((char *)&val, (TO)); \
-}
-extern void
-double_to_i387 PARAMS ((char *, char *));
+#undef REGISTER_BYTES
+#define REGISTER_BYTES (SIZEOF_GREGS + SIZEOF_FPU_REGS)
 
 #endif /* TM_I386AIX_H */
From scottb@netwinder.org Thu Mar 02 11:35:00 2000
From: Scott Bambrough <scottb@netwinder.org>
To: GDB Patches Mail List <gdb-patches@sourceware.cygnus.com>
Subject: Patches and the patch database...
Date: Thu, 02 Mar 2000 11:35:00 -0000
Message-id: <38BEC141.9D299C3B@netwinder.org>
X-SW-Source: 2000-03/msg00021.html
Content-length: 427

Hi guys,

I decided to exercise the patch database.  I sent a whole whack of patches to
get rid of the deprecated macros TARGET_BYTE_ORDER and
TARGET_BYTE_ORDER_SELECTABLE.  It might be useful to have an architecture field
on the web form.  That would make it easier to search for ARM patches for
instance.

Scott

-- 
Scott Bambrough - Software Engineer
REBEL.COM    http://www.rebel.com
NetWinder    http://www.netwinder.org
From ezannoni@cygnus.com Thu Mar 02 15:18:00 2000
From: Elena Zannoni <ezannoni@cygnus.com>
To: gdb-patches@sourceware.cygnus.com
Subject: PATCH corefiles reading on alpha-linux
Date: Thu, 02 Mar 2000 15:18:00 -0000
Message-id: <14526.63171.337788.889969@kwikemart.cygnus.com>
X-SW-Source: 2000-03/msg00022.html
Content-length: 1733

gdb/config/alpha/alpha-linux.mh lists core-regset.o as one of
the NATDEPFILES.
This causes _initialize_core_regset() to be called, and this in turn 
calls add_core_fns with bfd_target_elf_flavour.

Later on, _initialize_core_alpha() adds another core function
structure with the same flavour.  When a core file is loaded, this
causes a warning to be printed, because both function sets match the
expected bfd flavour.

I am going to check this in. OK?

Elena

Index: alpha-linux.mh
===================================================================
RCS file: /cvs/src/src/gdb/config/alpha/alpha-linux.mh,v
retrieving revision 1.1.1.3
diff -c -r1.1.1.3 alpha-linux.mh
*** alpha-linux.mh      1999/12/22 21:45:12     1.1.1.3
--- alpha-linux.mh      2000/03/02 23:15:59
***************
*** 2,8 ****
  XDEPFILES= ser-tcp.o
  XM_FILE= xm-alphalinux.h
  NAT_FILE= nm-linux.h
! NATDEPFILES= infptrace.o inftarg.o corelow.o core-regset.o alpha-nat.o \
        fork-child.o solib.o linux-thread.o lin-thread.o 
  
  LOADLIBES = -ldl -rdynamic
--- 2,8 ----
  XDEPFILES= ser-tcp.o
  XM_FILE= xm-alphalinux.h
  NAT_FILE= nm-linux.h
! NATDEPFILES= infptrace.o inftarg.o corelow.o alpha-nat.o \
        fork-child.o solib.o linux-thread.o lin-thread.o 
  
  LOADLIBES = -ldl -rdynamic

Index: ChangeLog
===================================================================
RCS file: /cvs/src/src/gdb/ChangeLog,v
retrieving revision 1.95
diff -c -r1.95 ChangeLog
*** ChangeLog   2000/03/02 15:44:27     1.95
--- ChangeLog   2000/03/02 23:17:32
***************
*** 1,3 ****
--- 1,8 ----
+ 2000-03-02  Elena Zannoni  <ezannoni@kwikemart.cygnus.com>
+ 
+       * config/alpha/alpha-linux.mh: Remove core-regset.o fron the
+       NATDEPFILES list.
+