From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tom Tromey To: Jim Blandy Cc: Michael Meissner , Tom Tromey , Jason Molenda , gdb-patches@sourceware.cygnus.com Subject: Re: patch management? Date: Thu, 18 Nov 1999 10:17:00 -0000 Message-id: <199911181817.KAA18832@ferrule.cygnus.com> References: <199911152157.QAA26389@zwingli.cygnus.com> <19991116101108.B23372@tiktok.cygnus.com> <19991116113818.B1587@cygnus.com> <199911162051.MAA17286@ferrule.cygnus.com> <19991117212650.B11794@tiktok.cygnus.com> X-SW-Source: 1999-q4/msg00289.html 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 To: Jason Molenda Cc: gdb-patches@sourceware.cygnus.com Subject: Re: getting patches organized Date: Thu, 18 Nov 1999 14:48:00 -0000 Message-id: 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 To: Jim Blandy 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> 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 To: Jim Blandy Cc: Michael Meissner , Tom Tromey , Jason Molenda , 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> <19991116113818.B1587@cygnus.com> <199911162051.MAA17286@ferrule.cygnus.com> <19991117212650.B11794@tiktok.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 To: Andrew Cagney Cc: Michael Meissner , 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> <19991116113818.B1587@cygnus.com> <199911162051.MAA17286@ferrule.cygnus.com> <19991117212650.B11794@tiktok.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 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 * 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; + + /* 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). */ >From guo@cup.hp.com Fri Nov 19 09:23:00 1999 From: Jimmy Guo To: Tom Tromey 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: 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