* Re: cvsup & sourceware repositories?
2000-03-16 16:29 cvsup & sourceware repositories? Jimmy Guo
@ 2000-03-16 16:37 ` Jim Kingdon
2000-04-01 0:00 ` Russ Allbery
2000-04-01 0:00 ` Jimmy Guo
2000-04-01 0:00 ` Andrew Cagney
2 siblings, 1 reply; 7+ messages in thread
From: Jim Kingdon @ 2000-03-16 16:37 UTC (permalink / raw)
To: Jimmy Guo; +Cc: gdb
> Otherwise, what is the easiest way to maintain local repository? I want
> to create a local repository containing gdb, dejagnu, and binutils
> products, and be able to automatically 'synchronize' with sourceware's
> every night or on demand (turn-key solution here).
I don't really know cvsup well enough to know just how it compares,
but we do have anonymous rsync of the CVS repository - see
http://sourceware.cygnus.com/sourceware/ for details.
From rra@stanford.edu Thu Mar 16 16:44:00 2000
From: Russ Allbery <rra@stanford.edu>
To: gdb@sourceware.cygnus.com
Subject: Re: cvsup & sourceware repositories?
Date: Thu, 16 Mar 2000 16:44:00 -0000
Message-id: <yld7ous9w5.fsf@windlord.stanford.edu>
References: <Pine.LNX.4.10.10003161728370.4096-100000@hpcll168.cup.hp.com> <bln3iig8e.fsf@rtl.cygnus.com>
X-SW-Source: 2000-03/msg00265.html
Content-length: 550
Jim Kingdon <kingdon@redhat.com> writes:
> I don't really know cvsup well enough to know just how it compares, but
> we do have anonymous rsync of the CVS repository - see
> http://sourceware.cygnus.com/sourceware/ for details.
It's roughly equivalent. CVSup may send less information (and hence be
more efficient) than rsync since it understands CVS repository structure,
and it produces slightly nicer diagnostic output, but for the most part
either are as good.
--
Russ Allbery (rra@stanford.edu) < http://www.eyrie.org/~eagle/ >
From ac131313@cygnus.com Thu Mar 16 16:51:00 2000
From: Andrew Cagney <ac131313@cygnus.com>
To: Jimmy Guo <guo@cup.hp.com>
Cc: gdb@sourceware.cygnus.com
Subject: Re: cvsup & sourceware repositories?
Date: Thu, 16 Mar 2000 16:51:00 -0000
Message-id: <38D18058.738B6F77@cygnus.com>
References: <Pine.LNX.4.10.10003161728370.4096-100000@hpcll168.cup.hp.com>
X-SW-Source: 2000-03/msg00266.html
Content-length: 959
Jimmy Guo wrote:
>
> <<sorry I sent the original question under a different subject line,
> here it is again!>>
>
> A general question about the repositories on sourceware:
> Can we use cvsup client tool to maintain a local repository? Instead of
> getting 'snapshots' via the CVS interfaces, I'd like to use the cvsup
> tool to get updates to the repositories. It requires sourceware to run
> a cvsupd daemon.
>
> Otherwise, what is the easiest way to maintain local repository? I want
> to create a local repository containing gdb, dejagnu, and binutils
> products, and be able to automatically 'synchronize' with sourceware's
> every night or on demand (turn-key solution here).
At present only rsync is available for this :-( See:
http://sourceware.cygnus.com/ml/overseers/2000/msg00102.html .
My things to do today list includes leaning on someone (....) so that
CVSupd runs on sourceware so that I can do the same thing from up here.
Andrew
From guo@cup.hp.com Thu Mar 16 18:44:00 2000
From: Jimmy Guo <guo@cup.hp.com>
To: gdb@sourceware.cygnus.com
Subject: Re: cvsup & sourceware repositories?
Date: Thu, 16 Mar 2000 18:44:00 -0000
Message-id: <Pine.LNX.4.10.10003161941510.6569-100000@hpcll168.cup.hp.com>
References: <Pine.LNX.4.10.10003161728370.4096-100000@hpcll168.cup.hp.com>
X-SW-Source: 2000-03/msg00267.html
Content-length: 409
OK, I pulled down rsync and built the socksified version. It appears to
be working. To get a replica of the GDB repository, what is the command
to use?
I tried:
% rsync --archive --delete --checksum --compress \
--stats rsync://sourceware.cygnus.com/gdb-cvs .
But that looks awfully small, only 313 files, and mostly the htdocs
stuff. I must have accessed the wrong module.
- Jimmy Guo, guo@cup.hp.com
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: cvsup & sourceware repositories?
2000-03-16 16:29 cvsup & sourceware repositories? Jimmy Guo
2000-03-16 16:37 ` Jim Kingdon
2000-04-01 0:00 ` Jimmy Guo
@ 2000-04-01 0:00 ` Andrew Cagney
2 siblings, 0 replies; 7+ messages in thread
From: Andrew Cagney @ 2000-04-01 0:00 UTC (permalink / raw)
To: Jimmy Guo; +Cc: gdb
Jimmy Guo wrote:
>
> <<sorry I sent the original question under a different subject line,
> here it is again!>>
>
> A general question about the repositories on sourceware:
> Can we use cvsup client tool to maintain a local repository? Instead of
> getting 'snapshots' via the CVS interfaces, I'd like to use the cvsup
> tool to get updates to the repositories. It requires sourceware to run
> a cvsupd daemon.
>
> Otherwise, what is the easiest way to maintain local repository? I want
> to create a local repository containing gdb, dejagnu, and binutils
> products, and be able to automatically 'synchronize' with sourceware's
> every night or on demand (turn-key solution here).
At present only rsync is available for this :-( See:
http://sourceware.cygnus.com/ml/overseers/2000/msg00102.html .
My things to do today list includes leaning on someone (....) so that
CVSupd runs on sourceware so that I can do the same thing from up here.
Andrew
From kettenis@wins.uva.nl Sat Apr 01 00:00:00 2000
From: Mark Kettenis <kettenis@wins.uva.nl>
To: ac131313@cygnus.com
Cc: gdb@sourceware.cygnus.com
Subject: Re: 5.0 known issues 2000-02-16
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <200002161409.e1GE9nh00758@delius.kettenis.local>
References: <38AA42EA.5106E153@cygnus.com>
X-SW-Source: 2000-q1/msg00310.html
Content-length: 1457
Date: Wed, 16 Feb 2000 17:25:46 +1100
From: Andrew Cagney <ac131313@cygnus.com>
Target Specific:
GNU/Linux/i386:
After gdb_proc_service.h patch, its results are:
# of expected passes 6363
# of unexpected failures 12
# of expected failures 200
but it didn't run the threads tests. I believe the solib.c problem is
still dangling. Actually, a testcase for what ever it is is needed
first.
Looks like I misinterpreted the test logs. The results above do
include running the thread tests. The relevant test script tries to
link with -lpthreads first, which fails on most systems, but then
tries -lpthread, which succeeds.
I am working on the solib.c problem. HJ reported that there is indeed
only a problem with dlclose(): GDB doesn't remove the shared library
from its list of loaded objects. As a consequence a subsequent
dlopen() isn't noticed by GDB. Basically my approach is based on a
patch from FreeBSD, but I'm changing things to minimize the amount of
data read from the target. I'll need a few more days, and this patch
really needs to be tested on some more platforms (at least SunOS 4)
before it can be integrated.
I have a test case. I'll try to integrate it in the test-suite.
Solaris: No feed back, I'll put it on my list of things to do.
I have successfully built GDB on Solaris 2.6, see:
http://sourceware.cygnus.com/ml/gdb-testers/2000-q1/msg00030.html
Mark
From eliz@delorie.com Sat Apr 01 00:00:00 2000
From: Eli Zaretskii <eliz@delorie.com>
To: gdb@sourceware.cygnus.com
Subject: Dependence on config.status
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <200002280657.BAA27090@indy.delorie.com>
X-SW-Source: 2000-q1/msg00431.html
Content-length: 330
defs_h in gdb/Makefile includes config.status. This makes all of the
GDB sources depend on it. The result is that each time I reconfigure
the package, everything gets recompiled, which is quite annoying when
working on some minor configury buglets.
Why does GDB need to be dependent on config.status, in addition to
config.h?
From jimb@cygnus.com Sat Apr 01 00:00:00 2000
From: Jim Blandy <jimb@cygnus.com>
To: gdb@sourceware.cygnus.com
Subject: patch database proposal
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <200002251827.NAA09955@zwingli.cygnus.com>
X-SW-Source: 2000-q1/msg00422.html
Content-length: 8847
Here's a tentative proposal for how the patch database should work.
In reality, a good part of this is set up and ready to go, but there's
nothing we can't revise, in the presence of good ideas or persuasive
criticism.
Please let me know what you think; post your comments to the list.
----
If you've written a patch for GDB, either to fix a bug or to improve
the program, you should make sure it gets into the GDB patch database.
The GDB patch database is a GNATS database created to help GDB's
maintainers keep track of patches that need reviewing, and helps you
stay on top of what's happening to your patch.
Anyone can submit a patch. There are two ways to do so:
- Visit the GDB Patch Submission page [Jason will supply URL], and
submit your patch there.
- Submit your patches via E-mail, by sending a message to
`gdb-patches-gnats@sourceware.cygnus.com'. We have a template for
mail messages [link here]. Following this template helps make sure
we have the information we need to choose a reviewer for your patch,
and to do the review itself.
We'd prefer that you use the web form, if possible, because that
provides more helpful prompts, and checks your input more thoroughly.
The database assigns each new patch a number, like `gdb-patch/209'.
Whenever you send mail regarding your patch, be sure to include the
address `gdb-patches-gnats@sourceware.cygnus.com' in the CC list, and
make sure the message subject starts with `gdb-patch/209: ', or
whatever your patch number is. This way, GNATS will automatically log
the discussion along with the patch in the database.
Once you've submitted your patch, you can visit [another URL] to check
on its status, or to search the patch database in various ways. Each
patch in the database has a set of headers, much like a mail message;
the two most interesting headers to look at are:
- `Responsible' --- this is the name of the person currently
responsible for moving the patch forward.
- `State' --- the current status of the patch.
Here are the different states a patch might be in:
- `unclaimed'
If the database software can't figure out automatically which
maintainer should evaluate your patch, then it declares the patch
`unclaimed', and sets the `Responsible' person to the GDB patch
secretary. It is then the secretary's job to find someone who can
review the patch, and change the patch's `State' and `Responsible'
headers appropriately.
Also, if the maintainer responsible for a patch decides that they
can't process it --- for example, they might know they won't be able
to evaluate it promptly --- then they can put it back in the
`unclaimed' state. As before, the patch secretary should find
someone else to tend to it. The patch database logs all changes
to a patch's state or responsible party, along with all mail
communication about the patch, which can help the new person pick
the patch where it left off.
- `claimed'
The person named in the patch's `Responsible' header has volunteered
or been designated to review the patch, but they haven't made any
decision about it yet, or they haven't gotten around to looking at
it yet.
The maintainer indicates his or her decision by putting the patch in
one of the states below.
If the patch requires additional maintainers' approval, then the
maintainer should leave the patch in the `claimed' state, and simply
change the `Responsible' field to the next maintainer in line.
Since all changes in responsibility are logged with the patch, each
maintainer can tell when the review process is complete. The last
maintainer to evaluate the patch should actually change the state to
something more conclusive.
As the name suggests, patch claims are voluntary. Maintainers
should feel free to claim interesting unclaimed patches for
themselves, and to trade or reallocate patches amongst themselves as
appropriate, simply by changing patches' `State' and `Responsible'
headers. Assignments made automatically by the database software,
or manually by the patch secretary, are simply an optimization,
meant to help the process run more smoothly.
Of course, if a maintainer consistently fails to review patches in a
timely fashion, the team will eventually suggest that they step
down, or share the responsibility with someone more responsive.
- `feedback'
This state indicates that the maintainer feels the patch needs
revision, or that the author's intent is unclear and the patch
should be further explained. It is now the responsibility of the
original author of the patch to satisfy the maintainer's concerns,
to allow the patch to move forward.
The maintainer's concerns should always be recorded with the patch
somehow, either in a mail message logged with the patch, or in the
state change message.
Note that the maintainer is still responsible for patches in this
state. If the author is slow to respond, the maintainer must pursue
the matter, or put the patch in the `rejected' state (described
below) if the author doesn't reply.
- `prereqs'
The maintainer approves of the patch, but can't apply it until some
other change is made --- some other patch must be applied first, for
example. The maintainer should explain what they are waiting for in
the patch record. It is the maintainer's responsibility to notice
when the prerequisites have been met, and move the patch along.
- `accepted'
The maintainer has decided to apply the patch, and has accepted
responsibility for whatever further work is necessary to get it into
the sources.
- `applied'
The maintainer has applied the patch, and expects no further work on
that patch to be necessary.
- `rejected'
This state represents several possible outcomes:
- The maintainer has decided that the patch should not be applied, and
is not expecting to do revisions or further work on that patch.
- The patch's author has withdrawn it, and the maintainer agrees.
- The patch is actually several smaller changes lumped together;
the author must resubmit it as several separate patches.
- The patch is so old that it is no longer useful in revising the
current sources, and neither the author nor the maintainer has any
intention of bringing it up to date.
In any case, the maintainer should explain why the patch was
rejected, in the patch notes.
Of course, it is always possible for a maintainer to resurrect a
rejected patch, simply by putting it back in one of the other
states.
- `papers'
The maintainer would like to apply the patch, but the patch is large
enough that it is automatically copyrighted by the author, and
cannot be applied to the GDB sources. In this case, the author
needs to assign his or her copyright interest in the patch to the
Free Software Foundation; see [link], or the file `gdb/CONTRIBUTE'
in the GDB source tree, for details about this.
[We'll work in full documentation for the other headers somewhere, but
this page is mostly about the process, which is the least obvious
part.]
If you're interested in monitoring patch activity, you may wish to
subscribe to `gdb-patches-prs@sourceware.cygnus.com'. This mailing
list receives:
- messages announcing newly submitted patches
- all discussion about existing patches
- messages indicating that a patch has changed state, and why
To subscribe, [appropriate instructions or link]
If you are having problems using the patch database, send mail to
`gdb-patches-secretary@sourceware.cygnus.com'. The patch secretary
is responsible for:
- the quality of the database (removing spam, getting people to use
the headers in a helpful way, making sure all patches are placed
in the database [in my experience, every database gets dirty, and
there needs to be someone working to counteract entropy]);
- passing `unclaimed' patches to willing and appropriate maintainers;
- all GDB-specific documentation and web pages supporting the patch
database; and
- any other administration specific to the GDB patch database
The patch secretary is not responsible for:
- technical issues (like evaluating patches);
- administration of shared sourceware infrastructure, not specific to the
GDB database (fixing wedged servers, upgrading software, etc.); or
- prodding unresponsive maintainers. (General community pressure is
best for this; beyond that, the prodding needs to be done by
someone with real authority over their time, like their manager,
or authority over their maintainership, like the committee that
made them a maintainer in the first place.)
In the GDB source tree, the file gdb/MAINTAINERS lists the current
patch secretary, along with all the maintainers and the areas they're
responsible for.
From P.Leggett@gre.ac.uk Sat Apr 01 00:00:00 2000
From: Peter Leggett <P.Leggett@gre.ac.uk>
To: gdb@sourceware.cygnus.com
Subject: gdb functionality query
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <20000228114844.A3717@gre.ac.uk>
X-SW-Source: 2000-q1/msg00432.html
Content-length: 1342
Hello,
I hope that this list is the appropriate one to ask a general
gdb question. If not please excuse this mail.
The research group I work in uses the Sun debugger/dbx which has some
these extremly useful features without which we would find debugging
our codes much harder. We are now also running on linux boxes
and are exploring the possibilites of gdb.
I would very much appreciate it if anyone could tell me if gdb has
the following specific functionality:-
a) Ability to pop program call frame stack and then continue. I know one
can browse up and down the frames in gdb but can one pop it and
continue from a calling frame up the stack.
b) make an arbitary call to user code (with possibly arguments and
expressions) from gdb and break point within that call etc..
e.g.
gdb-> break usersub
gdb-> call usersub(a,fred+2,jim*2+1)
...
where a, fred and kim are user variables.
Thank you
Pete
--
Dr Peter F. Leggett Tel: +44 (0)20-8331-8731
Parallel Processing Research Group Fax: +44 (0)20-8331-8665
University of Greenwich Email: P.Leggett@gre.ac.uk
Maritime Greenwich Campus Internet: http://www.gre.ac.uk/~lp01
30 Park Row
London SE10 9LS
^ permalink raw reply [flat|nested] 7+ messages in thread