Re: gdb weekly snapshots

[Eli Zaretskii <eliz@delorie.com>]

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