Re: patch management?

[Tom Tromey <tromey@cygnus.com>]

Jim> Here's a set of states which I think could do the job.  Do you
Jim> think these would work?

Jim> State: unclaimed
Jim> State: assigned

For the Java Gnats database we have a "java-hacker" "person" which is
really the unassigned state.  Does it make sense to go this way
instead?  I don't know.

T
From jimb@cygnus.com Thu Nov 18 14:48:00 1999
From: Jim Blandy <jimb@cygnus.com>
To: Jason Molenda <jsm@cygnus.com>
Cc: gdb-patches@sourceware.cygnus.com
Subject: Re: getting patches organized
Date: Thu, 18 Nov 1999 14:48:00 -0000
Message-id: <nphfij5sch.fsf@zwingli.cygnus.com>
References: <199911172343.SAA28254@zwingli.cygnus.com> <19991117161503.A15122@cygnus.com>
X-SW-Source: 1999-q4/msg00290.html
Content-length: 1667

> > The only system I'm really familiar with is GNATS.  GNATS can
> > automatically stash E-mail conversation related to a patch in the
> > patch record ("PR"), which is exactly what we want.  It's got web
> > interfaces, a decent query ability, and so on.  So I think it would
> > work great.
> 
> If folks are not familiar with GNATS and want to see what it looks like,
> bring up
> 
> 	http://sourceware.cygnus.com/cgi-bin/gnatsweb.pl
> 
> There are several active databases on here; select something like
> autoconf, automake or java and you can browse around read-only.

Right now, those pages seem organized around the capabilities of
GNATS.  This is nice, because if you know what you want to do in
GNATS, it's easy to figure out how to do it on the web.

But it's not organized around thing people actually want to do while
working on GDB (or whatever).  It would be better to have the home
page for the patch database give introductory information, and then
have a series of forms for the most common queries:

- Which patches have I submitted?  (result sorted by state: active
  patches first, applied and rejected patches at bottom.  links to
  individual patches.)
- Which patches am I responsible for?  (Same sort order.)
- Find me patches whose synopsis/body contains this string.  (Same
  sort order.)

... and maybe some others.  Maybe the home page should simply always
list all the active patches, if that's fast enough.

These are all easy to do with the query interface, but they're what
you always want, so they should be one-click operations.  I defined
Emacs keys to do common GNATS queries for me; this interface should be
at least that nice.
From crash@cygnus.com Thu Nov 18 15:03:00 1999
From: Jason Molenda <crash@cygnus.com>
To: Jim Blandy <jimb@cygnus.com>
Cc: gdb-patches@sourceware.cygnus.com
Subject: Re: getting patches organized
Date: Thu, 18 Nov 1999 15:03:00 -0000
Message-id: <19991118150355.E5316@cygnus.com>
References: <199911172343.SAA28254@zwingli.cygnus.com> <19991117161503.A15122@cygnus.com> <nphfij5sch.fsf@zwingli.cygnus.com>
X-SW-Source: 1999-q4/msg00291.html
Content-length: 1721

On Thu, Nov 18, 1999 at 05:48:30PM -0500, Jim Blandy wrote:

> > 	http://sourceware.cygnus.com/cgi-bin/gnatsweb.pl

> It would be better to have the home
> page for the patch database give introductory information, and then
> have a series of forms for the most common queries:
> 
> - Which patches have I submitted?  
> - Which patches am I responsible for?  
> - Find me patches whose synopsis/body contains this string.  

I haven't experimented with URLs directly into gnatsweb to pull out
reports like this, but I believe it to be possible.  Of course, because
it is the web I don't have a useful concept "I" -- a simple canned URL
isn't going to work.

Individuals can always set up a query of arbitrary complexity and save
that query; it gets stored in a cookie by your web browser.  To be honest,
I haven't much investigated stored queries either.

In any event, I believe these things are possible.  And if nothing else,
we always have the source and can create a second gnatsweb script hacked
especially for patches if that looks like it makes sense.  We've got
the power.

> These are all easy to do with the query interface, but they're what
> you always want, so they should be one-click operations.  I defined
> Emacs keys to do common GNATS queries for me; this interface should be
> at least that nice.

Why not just use the emacs interface, then?  The gnatsweb WWW interface
is great largely because it requires no installation on users' systems.
For people who are going to use gnats often, I recommend installing
one of the local clients.  The tcl/tk one, tkgnats, looks quite nice;
the emacs one is favored by many.  I personally have used the command
line ones for years.



Jason
Free the Software!
From ac131313@cygnus.com Thu Nov 18 17:25:00 1999
From: Andrew Cagney <ac131313@cygnus.com>
To: Jim Blandy <jimb@cygnus.com>
Cc: Michael Meissner <meissner@cygnus.com>, Tom Tromey <tromey@cygnus.com>, Jason Molenda <jsm@cygnus.com>, gdb-patches@sourceware.cygnus.com
Subject: Re: patch management?
Date: Thu, 18 Nov 1999 17:25:00 -0000
Message-id: <3834A6DB.74CC0A9B@cygnus.com>
References: <199911152157.QAA26389@zwingli.cygnus.com> <19991116101108.B23372@tiktok.cygnus.com> <npln7y70lt.fsf@zwingli.cygnus.com> <19991116113818.B1587@cygnus.com> <199911162051.MAA17286@ferrule.cygnus.com> <19991117212650.B11794@tiktok.cygnus.com> <nppux767s7.fsf@zwingli.cygnus.com>
X-SW-Source: 1999-q4/msg00292.html
Content-length: 1351

Jim Blandy wrote:
> 
> > I'm not familar with Gnats.  Ideally something like Clarify's work queues (hey
> > put down those basebats....) where a patch waiting to be reviewed sits in a
> > queue, and people can indicate that they are looking at the patch for those
> > patches that take more than 2 seconds of time to evaluate (so that you don't
> > have 3 people all looking at the patch at the same time) and/or approval.  It
> > would be nice if it could work with multiple branches (and especially handle
> > those things that go out into fsf, etc.), hopefully doing the checkin
> > automatically.  As a patch reviewer, I want to be able to see all patches that
> > are waiting for me personally to look at, and also patches that anybody in the
> > group can approve.  As a patch submitter, I want feedback on outstanding
> > patches.
> 
> The CVS stuff is a challenge.
> 
> But I think GNATS can do all the rest, just by choosing the right
> conventions.  These conventions should be explained somewhere really
> public, like on the GNATS query web page.  Every PR should have a
> header named "State-explanations:" whose value is the URL for the web
> page explaining them, so nobody forgets.

On the queue side, Clarify (oh no, not another one :-) allows you put
your tasks into a number of local work-in-progress bins.

Can I do that?

	Andrew
From crash@cygnus.com Thu Nov 18 17:32:00 1999
From: Jason Molenda <crash@cygnus.com>
To: Andrew Cagney <ac131313@cygnus.com>
Cc: Michael Meissner <meissner@cygnus.com>, gdb-patches@sourceware.cygnus.com
Subject: Re: patch management?
Date: Thu, 18 Nov 1999 17:32:00 -0000
Message-id: <19991118173256.B5754@cygnus.com>
References: <199911152157.QAA26389@zwingli.cygnus.com> <19991116101108.B23372@tiktok.cygnus.com> <npln7y70lt.fsf@zwingli.cygnus.com> <19991116113818.B1587@cygnus.com> <199911162051.MAA17286@ferrule.cygnus.com> <19991117212650.B11794@tiktok.cygnus.com> <nppux767s7.fsf@zwingli.cygnus.com> <3834A6DB.74CC0A9B@cygnus.com>
X-SW-Source: 1999-q4/msg00293.html
Content-length: 517

On Fri, Nov 19, 1999 at 12:24:43PM +1100, Andrew Cagney wrote:

> On the queue side, Clarify (oh no, not another one :-) allows you put
> your tasks into a number of local work-in-progress bins.
> 
> Can I do that?

No.  I think a front end could do it behind gnats' back; if it knew which
PRs you owned, it could separate them under your own set of categories.
I don't think anyone's ever done anything like this though.

I can't think of an obvious way to do that in GNATS right off hand.

Jason
Free the Software!
From tromey@cygnus.com Thu Nov 18 22:13:00 1999
From: Tom Tromey <tromey@cygnus.com>
To: gdb-patches@sourceware.cygnus.com 
Subject: Patch: gdb -vs- Debian 2.0
Date: Thu, 18 Nov 1999 22:13:00 -0000
Message-id: <8766yzgg67.fsf@cygnus.com>
X-SW-Source: 1999-q4/msg00294.html
Content-length: 5896

I'm still running Debian 2.0, kernel 2.0.34.  Recently gdb stopped
working on this platform.  I tracked this down to code in
i386-linux-nat.c which uses PTRACE_GETREGS, which is not implemented
in this kernel.

This patch fixes the problem by falling back on the old method when
ptrace fails.  I'm not entirely certain that the infptrace.c part of
this patch is correct (in particular, is it safe to unconditionally
compile the code that was formerly bracketed by
FETCH_INFERIOR_REGISTERS?).  For that matter, I'm not entirely sure
about the patch as a whole, though it does seem to work for me.

I didn't run the test suite since the results would be meaningless --
very little passed before this patch.

One concern might be: how much backwards compatibility do we want?  I
don't think Debian 2.0 is all that old, but others might think
differently.

Comments?  Questions?  Ok to commit?

1999-11-18  Tom Tromey  <tromey@cygnus.com>

	* i386-linux-nat.c (ptrace_getregs_fails): New global.
	(fetch_regs): Set ptrace_getregs_fails when appropriate.
	(fetch_inferior_registers): Call ptrace_fetch_inferior_registers
	when appropriate.
	(store_inferior_registers): Call ptrace_store_inferior_registers
	when appropriate.
	* infptrace.c (ptrace_fetch_inferior_registers): Renamed from
	fetch_inferior_registers.
	(ptrace_store_inferior_registers): Renamed from
	store_inferior_registers.
	(fetch_inferior_registers): New function.
	(store_inferior_registers): New function.

Tom

Index: i386-linux-nat.c
===================================================================
RCS file: /cvs/cvsfiles/devo/gdb/i386-linux-nat.c,v
retrieving revision 1.7
diff -u -r1.7 i386-linux-nat.c
--- i386-linux-nat.c	1999/11/03 21:12:27	1.7
+++ i386-linux-nat.c	1999/11/19 06:05:20
@@ -70,7 +70,13 @@
 #endif
 ;
 
+/* If nonzero, we've determined that this kernel does not support
+   PTRACE_GETREGS.  In this case we use the old-style ptrace support
+   when fetching or setting registers.  */
 
+static int ptrace_getregs_fails = 0;
+
+
 \f
 /* Transfering the general registers between GDB, inferiors and core files.  */
 
@@ -142,7 +148,15 @@
   ret = ptrace (PTRACE_GETREGS, inferior_pid, 0, (int) &buf);
   if (ret < 0)
     {
-      warning ("Couldn't get registers");
+      if (errno == EIO)
+	{
+	  /* Some Linux kernels don't support PTRACE_GETREGS.  We fall
+	     back to old-style ptrace support in that case.  */
+	  ptrace_getregs_fails = 1;
+	  ptrace_fetch_inferior_registers (-1);
+	}
+      else
+	warning ("Couldn't get registers");
       return;
     }
 
@@ -161,8 +175,18 @@
   ret = ptrace (PTRACE_GETREGS, inferior_pid, 0, (int) &buf);
   if (ret < 0)
     {
-      warning ("Couldn't get registers");
-      return;
+      if (errno == EIO)
+	{
+	  /* Some Linux kernels don't support PTRACE_SETREGS.  We fall
+	     back to old-style ptrace support in that case.  */
+	  ptrace_getregs_fails = 1;
+	  ptrace_fetch_inferior_registers (-1);
+	}
+      else
+	{
+	  warning ("Couldn't get registers");
+	  return;
+	}
     }
 
   convert_to_gregset (&buf, registers, register_valid);
@@ -521,13 +545,20 @@
 void
 fetch_inferior_registers (int regno)
 {
+  if (ptrace_getregs_fails)
+    {
+      ptrace_fetch_inferior_registers (regno);
+      return;
+    }
+
   /* 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.  */
   if (regno == -1)
     {
       fetch_regs ();
-      if (fetch_xfpregs ())
+      /* ptrace_getregs_fails might have just been set.  */
+      if (ptrace_getregs_fails || fetch_xfpregs ())
 	return;
       fetch_fpregs ();
       return;
@@ -570,13 +601,20 @@
 store_inferior_registers (regno)
      int regno;
 {
+  if (ptrace_getregs_fails)
+    {
+      ptrace_store_inferior_registers (regno);
+      return;
+    }
+
   /* Use the xfpregs requests whenever possible, since they transfer
      more registers in one system call.  But remember that
      fetch_xfpregs can fail, and return zero.  */
   if (regno == -1)
     {
       store_regs ();
-      if (store_xfpregs ())
+      /* ptrace_getregs_fails might have just been set.  */
+      if (ptrace_getregs_fails || store_xfpregs ())
 	return;
       store_fpregs ();
       return;
Index: infptrace.c
===================================================================
RCS file: /cvs/cvsfiles/devo/gdb/infptrace.c,v
retrieving revision 1.70
diff -u -r1.70 infptrace.c
--- infptrace.c	1999/08/08 07:19:46	1.70
+++ infptrace.c	1999/11/19 06:05:26
@@ -334,8 +334,6 @@
 #endif /* KERNEL_U_ADDR_BSD.  */
 }
 
-#if !defined (FETCH_INFERIOR_REGISTERS)
-
 #if !defined (offsetof)
 #define offsetof(TYPE, MEMBER) ((unsigned long) &((TYPE *)0)->MEMBER)
 #endif
@@ -397,7 +395,7 @@
    Otherwise, REGNO specifies which register (so we can save time). */
 
 void
-fetch_inferior_registers (regno)
+ptrace_fetch_inferior_registers (regno)
      int regno;
 {
   if (regno >= 0)
@@ -457,7 +455,7 @@
    Otherwise, REGNO specifies which register (so we can save time).  */
 
 void
-store_inferior_registers (regno)
+ptrace_store_inferior_registers (regno)
      int regno;
 {
   if (regno >= 0)
@@ -472,6 +470,31 @@
 	}
     }
 }
+
+#if !defined (FETCH_INFERIOR_REGISTERS)
+
+/* A wrapper for ptrace_fetch_inferior_registers.  On some platforms
+   we need ptrace_fetch_inferior_registers to be visible with a
+   different name.  */
+
+void
+fetch_inferior_registers (regno)
+     int regno;
+{
+  ptrace_fetch_inferior_registers (regno);
+}
+
+/* A wrapper for ptrace_store_inferior_registers.  On some platforms
+   we need ptrace_store_inferior_registers to be visible with a
+   different name. */
+
+void
+store_inferior_registers (regno)
+     int regno;
+{
+  ptrace_store_inferior_registers (regno);
+}
+
 #endif /* !defined (FETCH_INFERIOR_REGISTERS).  */
 \f
 
From guo@cup.hp.com Fri Nov 19 09:23:00 1999
From: Jimmy Guo <guo@cup.hp.com>
To: Tom Tromey <tromey@cygnus.com>
Cc: gdb-patches@sourceware.cygnus.com
Subject: Re: Patch: gdb -vs- Debian 2.0
Date: Fri, 19 Nov 1999 09:23:00 -0000
Message-id: <Pine.LNX.4.10.9911190919190.4001-100000@hpcll168.cup.hp.com>
References: <8766yzgg67.fsf@cygnus.com>
X-SW-Source: 1999-q4/msg00295.html
Content-length: 498

>One concern might be: how much backwards compatibility do we want?  I
>don't think Debian 2.0 is all that old, but others might think
>differently.

One more bit of information -- gdb used to compile on Linux Redhat 5.1
(the PC cannot be upgraded to more recent versions due to onboard SCSI
controller <-> Linux driver problem), but some time ago quite recently I
have to compile gdb on Linux Redhat 6.0, probably due to the same change
Tom's patch is trying to fix.

- Jimmy Guo, guo@cup.hp.com