Re: gdb weekly snapshots

Re: gdb weekly snapshots

[Jason Molenda]

[-- 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)
 

Re: gdb weekly snapshots

[Andrew Cagney]

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.

Re: gdb weekly snapshots

[Eli Zaretskii]

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