* Re: gdb weekly snapshots
2000-04-12 11:32 ` gdb weekly snapshots Jason Molenda
@ 2000-04-12 22:54 ` Andrew Cagney
2000-04-13 2:35 ` Eli Zaretskii
1 sibling, 0 replies; 3+ messages in thread
From: Andrew Cagney @ 2000-04-12 22:54 UTC (permalink / raw)
To: Jason Molenda; +Cc: gdb
Jason Molenda wrote:
>
> > Jonathan wrote:
>
> > > If it's considered better just to drop the non-dejagnu snapshots, can those
> > > instead be made the gdb.tar.bz2/insight.tar.bz2 hard links in whatever the
> > > script is (those names make for easier URLs to point people at), and remove
> > > the old snapshots please?
>
> Andrew wrote:
>
> > At present gdb+dejagnu.tar.bz2 and insight+dejagnu.tar.bz2 snapshots are
> > being created. The names best reflect what is really in the archive.
>
> Well yes, but why bother being pedantic? The filenames are all
> eight characters longer than they need to be, when the longer name
> provides no additional information. If you're going to download
> a gdb snapshot, you're going to get dejagnu, deal with it. Why
> burden the filenames with extraneous characters every day?
The name did two things: it differentiated its self from the smaller
gdb.tar.gz; the archive script would mapp ``co gdb dejagnu'' onto
``gdb+dejagnu''. Hmm, given that there is no longer a gdb.tar.bz2 I can
probably be less pedantic.
> > Also of interest is the weekly *-CVS-* file. It contains a full CVS
> > checkout (although right now it is a checkout of the GDB-5.0 branch).
>
> Is this actually useful? If someone does
>
> cvs -d ... -z9 co gdb
Suprisingly, when I stopped creating them, I was sent requests to put
them back! Chopping them back to once a week was a compromize. I
suspect it is quicker / easier to grab that then remember the correct
CVS options :-)
Andrew
From ac131313@cygnus.com Thu Apr 13 00:01:00 2000
From: Andrew Cagney <ac131313@cygnus.com>
To: Mark Kettenis <kettenis@wins.uva.nl>
Cc: gdb@sourceware.cygnus.com, msnyder@cygnus.com
Subject: Re: Disabling lin-thread.c module
Date: Thu, 13 Apr 2000 00:01:00 -0000
Message-id: <38F56FDE.A18A9165@cygnus.com>
References: <200004101237.OAA29849@landau.wins.uva.nl>
X-SW-Source: 2000-04/msg00061.html
Content-length: 1815
Mark Kettenis wrote:
>
> Since glibc-2.1.3 was released with a bogus definition for
> prfpregset_t (at least for Linux/i386[1]), we'll have to take some
> measures to make sure that GDB-5.0 will work with glibc-2.1.3.
>
> I see three possibilities:
>
> 1. Disable the lin-thread.c module by default, and provide a switch
> --enable-thread-db to enable the module, such that people can build
> the module if the headers have been fixed (for example when
> glibc-2.1.4 has been installed).
>
> 2. Provide the same switch, but use an autoconf test to check whether
> the prfpregset_t type is broken, and enable the module based on the
> result of that test.
>
> 3. Use an autoconf test to check whether the prfpregset_t type is
> broken, and let GDB work around it.
Using a cynical marketing approach :-)
GDB 5.0 is all about getting new features and being able to boast about
them. GDB 5.0 is also all about kick starting the public CVS repository
and getting real community development. I suspect that people in
mission critical situations will think twice about jumping on a new
radical GDB 5.0 when:
o they see an even/zero sub-version
(always a bad sign :-)
o they know a 5.1 is coming soon
With respect to thread_db, my understanding is that it is no less
functional (1) then the old GDB-4.18 while at the same time, definitely
being better architecturally designed (true?). No matter how much
testing effort is put in, it is always going to take a release before it
becomes stable. Enable it now, and 5.1 should be ok. Enable it in 5.1
and 5.2 (a year from now?) is likely stable :-/
The decision is between the thread and Linux maintainers. The thread
maintainer said ya, so linux maintainers?
enjoy,
Andrew :-)
(1) Is that a polite way of saying ``no more buggy''?
From Stephane.Bihan@arccores.com Thu Apr 13 01:33:00 2000
From: Stephane.Bihan@arccores.com
To: Andrew Cagney <ac131313@cygnus.com>
Cc: gdb@sourceware.cygnus.com
Subject: Re: Makefile setting
Date: Thu, 13 Apr 2000 01:33:00 -0000
Message-id: <OFC6C77343.9E18E252-ON802568C0.002E5E4F@risccores.com>
X-SW-Source: 2000-04/msg00062.html
Content-length: 786
> > the ARC supported implementation of gdb we are trying to achieve is
> > "extensible".
> > The register description is minimal in the sense that only the basecase
> > registers are described in REGISTER_NAMES.
> > This description is updated (more registers are added) when we connect to
the
> > simulator.
>
> Hmm, I'd suggest investigating the multi-arch framework. It better
> handles things like an architecture suddenly deciding it needs to be
> changed. A target can also forced multi-arch to re-select its
> architecture if needed.
>
> http://sourceware.cygnus.com/gdb/papers/multi-arch/
>
> For the register extensions, are they known by arcExtMap or are they
> obtained from the target?
>
They are extracted from the object file.
Thanks anyway for the paper.
Stephane.
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: gdb weekly snapshots
2000-04-12 11:32 ` gdb weekly snapshots Jason Molenda
2000-04-12 22:54 ` Andrew Cagney
@ 2000-04-13 2:35 ` Eli Zaretskii
1 sibling, 0 replies; 3+ messages in thread
From: Eli Zaretskii @ 2000-04-13 2:35 UTC (permalink / raw)
To: jason-swarelist; +Cc: gdb
> Date: Wed, 12 Apr 2000 11:31:28 -0700
> From: Jason Molenda <jason-swarelist@molenda.com>
>
> Andrew wrote:
>
> > Also of interest is the weekly *-CVS-* file. It contains a full CVS
> > checkout (although right now it is a checkout of the GDB-5.0 branch).
>
> Is this actually useful? If someone does
>
> cvs -d ... -z9 co gdb
>
> They'll get a cvs checkout of GDB (or add the branchname to get
> the branch) just as fast as if they'd grabbed the snapshot.
Not everyone has CVS installed on every development machine they use.
I, for one, only have CVS on one machine, which is not my main
development platform.
> I
> guess there is less load on sourceware if they download a
> pre-checked-out tarfile, but how many people actually do this in
> a week?
I use snapshots and *diff.bz2 files almost exclusively. I almost
never do "cvs up", for some valid reasons which I prefer not to go
into.
From dan@cgsoftware.com Thu Apr 13 08:19:00 2000
From: dan@cgsoftware.com (Daniel Berlin)
To: gdb@sourceware.cygnus.com
Subject: Bcache'ing as a speedup
Date: Thu, 13 Apr 2000 08:19:00 -0000
Message-id: <puruyqnz.fsf@dan.resnet.rochester.edu>
X-SW-Source: 2000-04/msg00066.html
Content-length: 434
Ya know, i was thinking (yes, dangerous, i know).
If we bcache every symbol/psymbol/minsym name, and i mean literally
every single one, couldn't we just do simple pointer compares (IE
a==b) rather than strcmp (assuming we weren't doing a strcmp_Iw, which
obviously would still need to be done), since if they were the same
string, they would *have* to be pointing to the same memory?
Wouldn't this be a pretty large speed win?
--Dan
From jlarmour@redhat.co.uk Thu Apr 13 10:47:00 2000
From: jlarmour@redhat.co.uk (Jonathan Larmour)
To: csim@iris.snu.ac.kr
Cc: gdb@sourceware.cygnus.com
Subject: Re: remote debugging stub for ep7212 processor
Date: Thu, 13 Apr 2000 10:47:00 -0000
Message-id: <200004131747.SAA09892@murgh.cygnus.co.uk>
References: <002d01bfa04a$e884bae0$d9792e93@snu.ac.kr>
X-SW-Source: 2000-04/msg00067.html
Content-length: 541
In article < 002d01bfa04a$e884bae0$d9792e93@snu.ac.kr > you write:
>Hi.
>I'm looking for GDB stub for remote debugging of ep7212 processor.
>Is there anyone who have experienced about that?
>If any, could you tell me where can I get it?
>If not, how can I make it myself?
eCos ( http://sourceware.cygnus.com/ecos/ ) can be configured to
build a stub for the EP7212 eval board.
Jifl
--
Red Hat, 35 Cambridge Place, Cambridge, UK. CB2 1NS Tel: +44 (1223) 728762
"Plan to be spontaneous tomorrow." || These opinions are all my own fault
From ezannoni@cygnus.com Thu Apr 13 11:49:00 2000
From: Elena Zannoni <ezannoni@cygnus.com>
To: shebs@apple.com
Cc: Elena Zannoni <ezannoni@cygnus.com>, gdb@sourceware.cygnus.com
Subject: Re: Rombug?
Date: Thu, 13 Apr 2000 11:49:00 -0000
Message-id: <14582.5795.222477.937414@kwikemart.cygnus.com>
References: <14580.48028.584337.869818@kwikemart.cygnus.com> <38F4CB79.D82B8C9F@apple.com>
X-SW-Source: 2000-04/msg00068.html
Content-length: 1696
I forgot to mention that another rombug hack is present in
symbol_file_command(). Same story, it gets the .text address from the
target side. Can I get rid of that too? It would simplify the code
quite a lot.
Elena
Stan Shebs writes:
> Elena Zannoni wrote:
> >
> > While cleaning up the syntax for add-symbol-file, I saw that that
> > command has a special syntax just for the rombug case. For rombug, one
> > doesn't need to specify the address of the .text section to load the
> > file at. For all the other cases, such address must instead be specified as
> > argument to the command. Needless to say, this little variation
> > complicates things quite a bit.
> >
> > When is rombug used and what exactly is it? There is a brief mention of
> > it in the gdb manual, but not enough for me to understand much.
> > Is it still in use?
>
> Rombug is the boot monitor for Microware's OS-9 / OS-9000 (yes, these are
> the guys that are suing Apple over having a version 9 of MacOS, believe
> it or not), so its role is similar to that of CygMon in eCos.
> remote-os9k.c is just another cheesy monitor interface, and probably
> hasn't been used in a long time, so I don't anybody will notice if it
> crumbles a little more. From surfing around Microware's web site
> (www.microware.com), it looks like they recommend their own proprietary
> debug protocol anyway.
>
> I'd recommend leaving out the special rombug hack, but putting extra
> notes in the sources and ChangeLog, so that if someone goes looking for
> it in the future, they won't wonder if they were hallucinating when they
> remembered some sort of rombug support in add-symbol-file.
>
> Stan
>
From jlarmour@redhat.co.uk Thu Apr 13 14:47:00 2000
From: Jonathan Larmour <jlarmour@redhat.co.uk>
To: insight@sourceware.cygnus.com, gdb@sourceware.cygnus.com
Subject: Insight remote output doesn't output to console window immediately
Date: Thu, 13 Apr 2000 14:47:00 -0000
Message-id: <38F6404E.5959A4E0@redhat.co.uk>
X-SW-Source: 2000-04/msg00069.html
Content-length: 1773
[ Sent to gdb and insight lists since ]
I've found a problem in insight that is surprisingly old - I can't imagine
how it's lived so long actually: output from a remote target doesn't get
sent to the console window as it arrives. Instead it is buffered up.
I believe the problem is because of Cagney's change to remote.c on July 2nd
1999 which changed remote_console_output to operate on the gdb_stdtarg
stream rather than gdb_stdout. But, in main.c, gdb_stdtarg is #defined to
gdb_stderr. Which means that it matches the following code in
gdbtk/generic/gdbtk-hooks.c in gdbtk_fputs():
if (result_ptr != NULL)
{
if (result_ptr->flags & GDBTK_TO_RESULT)
...
else if (stream == gdb_stderr || result_ptr->flags &
GDBTK_ERROR_ONLY)
{
if (result_ptr->flags & GDBTK_ERROR_STARTED)
Tcl_AppendToObj (result_ptr->obj_ptr, (char *) ptr, -1);
else
{
Tcl_SetStringObj (result_ptr->obj_ptr, (char *) ptr, -1);
result_ptr->flags |= GDBTK_ERROR_STARTED;
}
i.e. it is appended to result_ptr, rather than calling gdbtk_tcl_fputs to
display it in the console window.
The only thing I'm wondering about is the fix. We could #define gdb_stdtarg
to gdb_stdout instead. Or we could add a hook with set_ui_file_flush() so
that the "gdb_flush (gdb_stdtarg);" at the end of remote_console_output()
would do the right thing. I simply don't know which is the more correct fix
before I implement it, although I suspect the latter.
Let me know - I'd like to sort this out soon because it affects Insight 5
(?) as well. Ta,
Jifl
--
Red Hat, 35 Cambridge Place, Cambridge, UK. CB2 1NS Tel: +44 (1223) 728762
"Plan to be spontaneous tomorrow." || These opinions are all my own fault
From kettenis@wins.uva.nl Thu Apr 13 15:12:00 2000
From: Mark Kettenis <kettenis@wins.uva.nl>
To: ac131313@cygnus.com
Cc: gdb@sourceware.cygnus.com, msnyder@cygnus.com
Subject: Re: Disabling lin-thread.c module
Date: Thu, 13 Apr 2000 15:12:00 -0000
Message-id: <200004132146.e3DLk2013680@delius.kettenis.local>
References: <200004101237.OAA29849@landau.wins.uva.nl> <38F56FDE.A18A9165@cygnus.com>
X-SW-Source: 2000-04/msg00070.html
Content-length: 1805
Date: Thu, 13 Apr 2000 16:57:34 +1000
From: Andrew Cagney <ac131313@cygnus.com>
GDB 5.0 is all about getting new features and being able to boast about
them. GDB 5.0 is also all about kick starting the public CVS repository
and getting real community development. I suspect that people in
mission critical situations will think twice about jumping on a new
radical GDB 5.0 when:
o they see an even/zero sub-version
(always a bad sign :-)
o they know a 5.1 is coming soon
With respect to thread_db, my understanding is that it is no less
functional (1) then the old GDB-4.18 while at the same time, definitely
being better architecturally designed (true?). No matter how much
testing effort is put in, it is always going to take a release before it
becomes stable. Enable it now, and 5.1 should be ok. Enable it in 5.1
and 5.2 (a year from now?) is likely stable :-/
Since GDB 4.18 didn't support threads on Linux GDB 5.0 will certainly
be `no less functional' :-).
Unfortunately people will compare 5.0 to HJ's "improved" 4.17 based
version. I suspect that that version still does handle threads
somewhat better than the current code in 5.0. But I guess our only
chance to improve things is getting the code out, and hope that people
will dump HJ's version when they discover all the nifty new features
in GDB 5.0, and see that we're actually fixing the bugs thet reported :-).
Anyhow, the strongest argument for shipping the libthread_db code is
that this will put an end to the practice of fixing GDB over and over
again when the internals of the LinuxThreads library are changed.
The decision is between the thread and Linux maintainers. The thread
maintainer said ya, so linux maintainers?
That's a `ja' from me to :-).
Mark
From ac131313@cygnus.com Thu Apr 13 16:53:00 2000
From: Andrew Cagney <ac131313@cygnus.com>
To: Jonathan Larmour <jlarmour@redhat.co.uk>
Cc: insight@sourceware.cygnus.com, gdb@sourceware.cygnus.com
Subject: Re: Insight remote output doesn't output to console window immediately
Date: Thu, 13 Apr 2000 16:53:00 -0000
Message-id: <38F65D4D.8B390EFA@cygnus.com>
References: <38F6404E.5959A4E0@redhat.co.uk>
X-SW-Source: 2000-04/msg00071.html
Content-length: 2316
Jonathan Larmour wrote:
>
> [ Sent to gdb and insight lists since ]
>
> I've found a problem in insight that is surprisingly old - I can't imagine
> how it's lived so long actually: output from a remote target doesn't get
> sent to the console window as it arrives. Instead it is buffered up.
>
> I believe the problem is because of Cagney's change to remote.c on July 2nd
> 1999 which changed remote_console_output to operate on the gdb_stdtarg
> stream rather than gdb_stdout. But, in main.c, gdb_stdtarg is #defined to
> gdb_stderr. Which means that it matches the following code in
> gdbtk/generic/gdbtk-hooks.c in gdbtk_fputs():
Yes, most likely :-(
> if (result_ptr != NULL)
> {
> if (result_ptr->flags & GDBTK_TO_RESULT)
> ...
> else if (stream == gdb_stderr || result_ptr->flags &
> GDBTK_ERROR_ONLY)
> {
> if (result_ptr->flags & GDBTK_ERROR_STARTED)
> Tcl_AppendToObj (result_ptr->obj_ptr, (char *) ptr, -1);
> else
> {
> Tcl_SetStringObj (result_ptr->obj_ptr, (char *) ptr, -1);
> result_ptr->flags |= GDBTK_ERROR_STARTED;
> }
>
> i.e. it is appended to result_ptr, rather than calling gdbtk_tcl_fputs to
> display it in the console window.
>
> The only thing I'm wondering about is the fix. We could #define gdb_stdtarg
> to gdb_stdout instead. Or we could add a hook with set_ui_file_flush() so
> that the "gdb_flush (gdb_stdtarg);" at the end of remote_console_output()
> would do the right thing. I simply don't know which is the more correct fix
> before I implement it, although I suspect the latter.
There is no need for another hook. Even the existing hooks
(gdbtk_fputs() and gdbtk_flush()) can, in theory, deleted. To see how
it should work, check the MI (mi/mi-main.c) - it maintains a separate
stream.
(BTW, sending the output gdb_stdout is wrong in CLI mode. gdb_stdout is
paged. Having ``more ....'' appear part way through target output in
CLI mode is only a little less frustrating than delayed output in GUI
mode :-)
As for a quick hack?
My first guess is to, when the GUI is enabled (ie not CLI mode),
re-route gdb_stdtarg to gdb_stdout. That might be suitable for the
branch. However, the trunk, needs to start taking advantage of ``struct
ui_out''.
Andrew
From jingham@cygnus.com Thu Apr 13 16:56:00 2000
From: James Ingham <jingham@cygnus.com>
To: Andrew Cagney <ac131313@cygnus.com>
Cc: Jonathan Larmour <jlarmour@redhat.co.uk>, insight@sourceware.cygnus.com, gdb@sourceware.cygnus.com
Subject: Re: Insight remote output doesn't output to console window immediately
Date: Thu, 13 Apr 2000 16:56:00 -0000
Message-id: <14582.24424.847207.786618@leda.cygnus.com>
References: <38F6404E.5959A4E0@redhat.co.uk> <38F65D4D.8B390EFA@cygnus.com>
X-SW-Source: 2000-04/msg00072.html
Content-length: 480
Andrew,
>
>
> As for a quick hack?
>
> My first guess is to, when the GUI is enabled (ie not CLI mode),
> re-route gdb_stdtarg to gdb_stdout. That might be suitable for the
> branch. However, the trunk, needs to start taking advantage of ``struct
> ui_out''.
>
Yup, this is pretty high on the to-do list, pretty close after
rewriting the source window code so it is maintainable, and figuring
out how to handle hangs in target communication more gracefully.
Jim
From ac131313@cygnus.com Thu Apr 13 19:41:00 2000
From: Andrew Cagney <ac131313@cygnus.com>
To: Stephane.Bihan@arccores.com
Cc: gdb@sourceware.cygnus.com
Subject: Re: multi-arch (was Re: Makefile setting)
Date: Thu, 13 Apr 2000 19:41:00 -0000
Message-id: <38F684CE.C1C8AD3@cygnus.com>
References: <OF170A1ECC.3969B3DA-ON802568C0.003270B9@risccores.com>
X-SW-Source: 2000-04/msg00073.html
Content-length: 2433
Stephane.Bihan@arccores.com wrote:
>
> Stephane.Bihan@arccores.com wrote:
> > >
> > > > > the ARC supported implementation of gdb we are trying to achieve is
> > > > > "extensible".
> > > > > The register description is minimal in the sense that only the
> basecase
> > > > > registers are described in REGISTER_NAMES.
> > > > > This description is updated (more registers are added) when we connect
> to
> > > the
> > > > > simulator.
> > > >
> > > > Hmm, I'd suggest investigating the multi-arch framework. It better
> > > > handles things like an architecture suddenly deciding it needs to be
> > > > changed. A target can also forced multi-arch to re-select its
> > > > architecture if needed.
> > > >
> > > > http://sourceware.cygnus.com/gdb/papers/multi-arch/
> > > >
> > > > For the register extensions, are they known by arcExtMap or are they
> > > > obtained from the target?
> > > >
> > > They are extracted from the object file.
> >
> > Good, multi-arch should definitly help. When a new object file is
> > presented to GDB the multi-arch framework is asked to identify it and
> > create an architecture for it. arc-tdep.c can be set up to identify
> > that information and set up things like the REGISTER_NAME
> > (REGISTER_NAMES is being given the boot :-) for the relevant target.
> >
> > Just a few speed bumps to climb over before it starts to help.
>
> That's a really good idea this multi-arch proposal!
A better description is probably a road map. MIPS, IA-64, D10V already
make use of the basic framework Several others (mn10300, SPARC, i386)
are all well down that same path. The rs6000 and SH are both on the hit
list.
> Just a shame I didn't read the paper before.
> I've implemented the REGISTER_NAMES initialisation in another way now.
> And I haven't got too much time to change it before sending you the sources of
> our ARC port.
To be clear and up front.
If someone contributes support for some new architecture then that new
architecture will need to use the multi-arch framework (see IA-64).
If someone contributes changes/fixes to an old target/architecture
(which would be your case I think) then those changes will need to be in
line with the general direction that multi-arch is taking. Post the
changes and lets see where it stands. It hopefully just involves simple
things like replacing your #define REGISTER_NAMES with #define
REGISTER_NAME(i) (arc_register_name (i)).
Andrew
From Stephane.Bihan@arccores.com Fri Apr 14 02:24:00 2000
From: Stephane.Bihan@arccores.com
To: Andrew Cagney <ac131313@cygnus.com>
Cc: gdb@sourceware.cygnus.com, Stephane.Bihan@arccores.com
Subject: Re: multi-arch (was Re: Makefile setting)
Date: Fri, 14 Apr 2000 02:24:00 -0000
Message-id: <OF381D754A.559EDC7A-ON802568C1.00327448@risccores.com>
X-SW-Source: 2000-04/msg00074.html
Content-length: 1611
> >
> > That's a really good idea this multi-arch proposal!
>
> A better description is probably a road map. MIPS, IA-64, D10V already
> make use of the basic framework Several others (mn10300, SPARC, i386)
> are all well down that same path. The rs6000 and SH are both on the hit
> list.
I can't see any multi-arch implementation in the current gdb-4.18 sources. I
can't see either any IA64 port.
>
> > Just a shame I didn't read the paper before.
> > I've implemented the REGISTER_NAMES initialisation in another way now.
> > And I haven't got too much time to change it before sending you the
sources of
> > our ARC port.
>
> To be clear and up front.
>
> If someone contributes support for some new architecture then that new
> architecture will need to use the multi-arch framework (see IA-64).
>
> If someone contributes changes/fixes to an old target/architecture
> (which would be your case I think) then those changes will need to be in
> line with the general direction that multi-arch is taking. Post the
> changes and lets see where it stands.
There is quite a few changes actually.
there is the simulator developped by Chameleon Inc, a remote-arc target (which
is a copy of remote.c a bit extended for our hardware target), some others
files to read the extensions and build a map of them, the arc-disassembler
totally changed to take these extensions into account.
> It hopefully just involves simple
> things like replacing your #define REGISTER_NAMES with #define
> REGISTER_NAME(i) (arc_register_name (i)).
As soon as I will find a roadmap, I'll do these changes.
Cheers,
Stephane.
^ permalink raw reply [flat|nested] 3+ messages in thread