Re: gdb weekly snapshots

[Jason Molenda <jason-swarelist@molenda.com>]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 10637 bytes --]

> 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?

> 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.  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?  Is this common enough to make all the mirror sites download
a copy of this file every week?

> With respect to pointing gdb.tar.bz2 -> gdb+dejagnu.tar.bz2.  The mirror
> sites probably won't like it.  Like a separate gdb.tar.bz2 archive
> (which is what I was doing) it would just increase the amount of mirror
> data being shipped out each night.


IMO including dejagnu in the nightly snapshots is not a big deal.
Include it, don't uglify the snapshotnames with +dejagnu, and everyone
is happy.


J
From shebs@apple.com Wed Apr 12 12:16:00 2000
From: Stan Shebs <shebs@apple.com>
To: Elena Zannoni <ezannoni@cygnus.com>
Cc: gdb@sourceware.cygnus.com
Subject: Re: Rombug?
Date: Wed, 12 Apr 2000 12:16:00 -0000
Message-id: <38F4CB79.D82B8C9F@apple.com>
References: <14580.48028.584337.869818@kwikemart.cygnus.com>
X-SW-Source: 2000-04/msg00054.html
Content-length: 1370

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 ezannoni@cygnus.com Wed Apr 12 12:18: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: Wed, 12 Apr 2000 12:18:00 -0000
Message-id: <14580.52252.842641.933519@kwikemart.cygnus.com>
References: <14580.48028.584337.869818@kwikemart.cygnus.com> <38F4CB79.D82B8C9F@apple.com>
X-SW-Source: 2000-04/msg00055.html
Content-length: 1532

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.

Aha! Excellent.

 > 
 > 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.
 > 

Whoohoo! Wonderful!


 > Stan
 > 

Thanks
Elena
From ac131313@cygnus.com Wed Apr 12 19:33:00 2000
From: Andrew Cagney <ac131313@cygnus.com>
To: rearnsha@arm.com
Cc: gdb@sourceware.cygnus.com
Subject: Re: Finding runtest
Date: Wed, 12 Apr 2000 19:33:00 -0000
Message-id: <38F53184.E606882D@cygnus.com>
References: <200004121100.MAA17801@cam-mail2.cambridge.arm.com>
X-SW-Source: 2000-04/msg00056.html
Content-length: 917

Richard Earnshaw wrote:
> 
> gdb comes with dejagnu as part of the distribution (to ensure we use one
> with the correct features).  Most of the time, the make system will pick
> this up automatically and use it in preference to any version that is
> installed on the path.  Unfortunately, this is not the case when checking
> dejagnu itself.  In this case, it will only work using a version that has
> already been installed.
> 
> The effect of this is that "make check" will fail when trying to check
> dejagnu if dejagnu has not been previously installed on the path.
> 
> I'm not entirely convinced that it is correct for a test program to be
> testing itself, but the current behaviour is a bit inconsistent.
> 
> Sorry no patch at the moment (I only came across this at home last night)
> and haven't had chance to fix it yet.

FYI, I suspect people have ``make check-gdb'' engrained in their
fingers.

	Andrew
From ac131313@cygnus.com Wed Apr 12 19:39:00 2000
From: Andrew Cagney <ac131313@cygnus.com>
To: Stephane.Bihan@arccores.com
Cc: gdb@sourceware.cygnus.com
Subject: Re: Makefile setting
Date: Wed, 12 Apr 2000 19:39:00 -0000
Message-id: <38F532C5.1D6195F8@cygnus.com>
References: <OF0153B737.255C7F44-ON802568BE.002C47F0@risccores.com>
X-SW-Source: 2000-04/msg00057.html
Content-length: 718

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?

	Andrew
From ac131313@cygnus.com Wed Apr 12 19:41:00 2000
From: Andrew Cagney <ac131313@cygnus.com>
To: gregerhaga@yahoo.com
Cc: "gdb@sourceware.cygnus.com" <gdb@sourceware.cygnus.com>
Subject: Re: interfacing to the gdb
Date: Wed, 12 Apr 2000 19:41:00 -0000
Message-id: <38F5335C.1C91220E@cygnus.com>
References: <38F2A2B1.D92467@yahoo.com>
X-SW-Source: 2000-04/msg00058.html
Content-length: 661

Greger Haga wrote:
> 
> Hi all,
> 
> I was just wondering how does the gdb work with interface, I am in the
> process ( a long process ) of writing a IDE for linux and would like
> to incorporate the gdb in it, and would like to know how to interface
> to it, any input much appreciated.

Were you looking to have gdb linked into your application or as a
separate program. If it is a separate program, then I'd look at the MI
interface (see gdb/mi/gdbmi.texinfo).

If you're looking to link gdb in then the longer term libGDB objective
may be more relevant.  The MI interface as a set of function calls is
what is hoped libGDB will eventually provide.

	Andrew
From gregerhaga@yahoo.com Wed Apr 12 22:38:00 2000
From: Greger Haga <gregerhaga@yahoo.com>
To: Andrew Cagney <ac131313@cygnus.com>, "gdb@sourceware.cygnus.com" <gdb@sourceware.cygnus.com>
Subject: Re: interfacing to the gdb
Date: Wed, 12 Apr 2000 22:38:00 -0000
Message-id: <38F547D4.45D5AF2C@yahoo.com>
References: <38F2A2B1.D92467@yahoo.com> <38F5335C.1C91220E@cygnus.com>
X-SW-Source: 2000-04/msg00059.html
Content-length: 1266

Andrew Cagney wrote:
Greger Haga wrote:
>
> Hi all,
>
> I was just wondering how does the gdb work with interface, I am in
the
> process ( a long process ) of writing a IDE for linux and would like
> to incorporate the gdb in it, and would like to know how to interface
> to it, any input much appreciated.

Were you looking to have gdb linked into your application or as a
separate program. If it is a separate program, then I'd look at the
MI
interface (see gdb/mi/gdbmi.texinfo).

If you're looking to link gdb in then the longer term libGDB objective
may be more relevant.  The MI interface as a set of function calls
is
what is hoped libGDB will eventually provide.
I really don't know. I need a way of interfacing to it. gdb can
be run as a separate thread or process. I want to build a gui to it, be
able to send commands to it and retrieve information about the debugging
process, I am in a long process of writing a IDE for linux, might take
years actually and started to think about how to interface to a debugger.
I don't know anything about the topic so any ideas about how to do this
is much appreciated. Ideally it would be integrated into the IDE that would
be best.

Greger
 

        Andrew
 
-- 
Greger Haga (gregerhaga@yahoo.com)