Re: GDB on FreeBSD/Alpha

Re: GDB on FreeBSD/Alpha

[Mark Kettenis]

   Date: Mon, 29 May 2000 19:25:10 -0400
   From: Anatoly Vorobey <mellon@pobox.com>
   Cc: obrien@FreeBSD.ORG, gdb@sourceware.cygnus.com
   Content-Type: text/plain; charset=us-ascii

   You, Mark Kettenis, were spotted writing this on Tue, May 30, 2000
   at 01:09:45AM +0200:
   > 
   >  -g     This generates stabs-in-ecoff debugging information (which is
   >         embedded in an .mdebug section in ELF).  GDB's support for
   >         this particular format has suffered from some bit rot, but it
   >         isn't too difficult fix.  The code is also used on MIPS, so I
   >         guess this would be appreciate by a some other people too.
   >         Looking through the code, there are several places where
   >         stabs-in-ecoff is commented on as being a (temporary) hack.

   Unless I'm mistaken, gcc doesn't know anything about ecoff -- it just
   outputs stabs. gas is the program which makes the decision to use
   stabs-in-ecoff. Please correct me if I'm wrong. 

Well, GCC knows some ecoff; it outputs .ent, .frame and .mask
pseudo-ops.  Basically enough to record the ecoff frame info,
something that stabs doesn't support very well.  But nothing beyond
that AFAICT.  It's indeed the job of the assembler to convert
everthing into the right format.

   I'm not at all an expert on Alpha, hence the following question might
   be silly, but -- is it possible for gcc/gas on FreeBSD/Alpha to generate
   true stabs (i.e. .stab and .stabstr sections) instead of stabs-in-ecoff?
   What would be wrong with this? 

You'll lose the frame info, which is quite essential for debugging,
and might also be used for exception handling.

   > 	A bigger problem is that GCC 2.95.2 doesn't output the right
   > 	stabs for function arguments (and perhaps for local variables
   > 	under some special circumstances).  This makes debugging
   > 	really painful, since function arguments will most likely have
   > 	the wrong values in GDB.  The GCC bug is fixed in the
   > 	development tree.

   I understand that David is going to give us gcc 2.96 on FreeBSD soon.
   Is the bug fixed there?

Well, 2.96 is just the version number used in the current tree.  There
is no official release yet, and AFAIK the next release will be GCC
3.0.  I guess the answer will be, yes it will be fixed.

   > In the long run I'd advice FreeBSD/Alpha to standardize in DWARF 2,
   > since it is used on more platforms.  

   I would argue against this. Wouldn't it be better for FreeBSD/Alpha
   to stay with stabs, in particular to maintain uniformity with FreeBSD/i386?
   I admit I have a private interest in staying with stabs too -- I have
   my own pet project which is kernel debugger support for stabs in FreeBSD,
   in a working shape on i386 now. I'm not too thrilled about adding DWARF2
   support there as well and bloating it out of bounds; till now I thought
   I'd only need to recover stabs from stabs-in-ecoff on Alpha.

What I'm suggesting, is making DWARF 2 the default format on FreeBSD.
You could still have stabs by passing -gstabs to GCC, and GDB would
in principle still support it (although it might suffer from bit-rot
if it isn't widely used anymore).

   What are the advantages of DWARF2 versus stabs?

Dan already answered that :-).

Mark
From fnasser@cygnus.com Tue May 30 06:47:00 2000
From: Fernando Nasser <fnasser@cygnus.com>
To: rearnsha@arm.com
Cc: Nicolas.Thery@Symbian.com, gdb@sourceware.cygnus.com
Subject: Re: ARM/linux gdb stops and gives no info
Date: Tue, 30 May 2000 06:47:00 -0000
Message-id: <3933C65A.CB1626B1@cygnus.com>
References: <200005300948.KAA21133@cam-mail2.cambridge.arm.com>
X-SW-Source: 2000-05/msg00161.html
Content-length: 3160

Richard Earnshaw wrote:
> 
> >
> > Richard Earnshaw <rearnsha@arm.com> wrote:
> >
> > > I can understand not being able to unpick the stack frame if I've jumped
> > > to never-never land, but to not even be able to display the registers
> > > makes the debugger useless.
> >
> > Have you tried "print $pc", "print $r1", ... to get the register contents?
> >
> 
> Thanks for the tip: yes, that works.  However, I still think that "info
> reg" should display the raw registers if there is no valid stack frame.
> 

Peter Schauer added the test for NULL frames in there back in 1995.  I believe
it was causing core dumps, but I am not sure as the ChangeLog entry does not give
the motive (we nowadays make sure it does, but that was not always true at the time):

     * infcmd.c (registers_info):  Error out if selected_frame is NULL.

I believe the default gdb routine (if the target does not define DO_REGISTERS_INFO)
does not depend on selected_frame but I can't be sure about all targets.

I quickly created the patch below.  I have no time to test it these days.
If you care applying it to your sources and trying I would appreciate.
Otherwise it goes in my 25 pages long TODO list.. ;-)

Regards,
Fernando

-- 
Fernando Nasser
Red Hat - Toronto                       E-Mail:  fnasser@cygnus.com
2323 Yonge Street, Suite #300           Tel:  416-482-2661 ext. 311
Toronto, Ontario   M4P 2C9              Fax:  416-482-6299



Index: infcmd.c
===================================================================
RCS file: /cvs/src/src/gdb/infcmd.c,v
retrieving revision 1.1.1.17
diff -c -p -r1.1.1.17 infcmd.c
*** infcmd.c    2000/02/03 04:14:31     1.1.1.17
--- infcmd.c    2000/05/30 13:42:23
*************** char *gdb_register_names[] = REGISTER_NA
*** 1494,1501 ****
     is required, (eg, for MIPS or Pyramid 90x, which both have
     lots of regs), or there is an existing convention for showing
     all the registers, define the macro DO_REGISTERS_INFO(regnum, fp)
!    to provide that format.  */
  
  #if !defined (DO_REGISTERS_INFO)
  
  #define DO_REGISTERS_INFO(regnum, fp) do_registers_info(regnum, fp)
--- 1494,1504 ----
     is required, (eg, for MIPS or Pyramid 90x, which both have
     lots of regs), or there is an existing convention for showing
     all the registers, define the macro DO_REGISTERS_INFO(regnum, fp)
!    to provide that format.
  
+    This default routine must work even if there is no selected_frame (== NULL).
+    Please don't add any dependencies on that being defined. */
+ 
  #if !defined (DO_REGISTERS_INFO)
  
  #define DO_REGISTERS_INFO(regnum, fp) do_registers_info(regnum, fp)
*************** registers_info (addr_exp, fpregs)
*** 1617,1624 ****
--- 1620,1633 ----
  
    if (!target_has_registers)
      error ("The program has no registers now.");
+ 
+ #if !defined (DO_REGISTERS_INFO)
+   /* The default do_registers_info() does not need the selected_frame
+      so we don't test for it not being NULL. Tagets that define
+      DO_REGISTERS_INFO may rely on that, so we make sure it is valid. */
    if (selected_frame == NULL)
      error ("No selected frame.");
+ #endif
  
    if (!addr_exp)
      {
From fnasser@cygnus.com Tue May 30 07:00:00 2000
From: Fernando Nasser <fnasser@cygnus.com>
To: shebs@apple.com
Cc: Michael Snyder <msnyder@cygnus.com>, gdb@sourceware.cygnus.com
Subject: Re: [RFD]: deprecate the "fg" command
Date: Tue, 30 May 2000 07:00:00 -0000
Message-id: <3933C98C.43C402B6@cygnus.com>
References: <8gn1pc$as9$1@cronkite.cygnus.com> <392F0D07.8116804F@apple.com>
X-SW-Source: 2000-05/msg00162.html
Content-length: 1064

Stan Shebs wrote:
> 
> Michael Snyder wrote:
> >
> > Does anybody use the "fg" command (a synonym for continue)?
> > It's been in there since 1991, but never documented.  I'd like to
> > deprecate it to reduce clutter and the hazard of dangerous typos.
> > If you tried to say "f" (the frame command) and your finger hit
> > two keys by accident, the result would be an unintentional continue,
> > which is generally a bad thing.
> 
> I'm agreeable.  In fact, I think we discussed using "fg" and "bg" as
> commands to control multiple processes for when we implemented
> multiple-process-debugging, in which case having fg mean something
> else already would be bad.
> 

Me too.

Can someone submit a patch for this using David Whedon's deprecate facility?
It seems from the text above that someone has already volunteered... ;-)

Thanks,
Fernando

-- 
Fernando Nasser
Red Hat - Toronto                       E-Mail:  fnasser@cygnus.com
2323 Yonge Street, Suite #300           Tel:  416-482-2661 ext. 311
Toronto, Ontario   M4P 2C9              Fax:  416-482-6299
From stewart@netwinder.org Tue May 30 07:40:00 2000
From: Rod Stewart <stewart@netwinder.org>
To: libc-alpha@sourceware.cygnus.com, gcc@gcc.gnu.org, linux-arm@vger.rutgers.edu, binutils@sourceware.cygnus.com, gdb@sourceware.cygnus.com
Subject: [Comments?] Nightly build of GNU tool chains. (fwd)
Date: Tue, 30 May 2000 07:40:00 -0000
Message-id: <Pine.LNX.4.10.10005301036440.30482-100000@kei.netwinder.org>
X-SW-Source: 2000-05/msg00163.html
Content-length: 2112

We, at Rebel.com, are now running nightly builds of some of the GNU tool
chains from CVS.  Currently we are building the following tool chains:
	GNU Binary Utilities (binutils)
	GNU C Library (glibc)
	GNU Compiler Collection (egcs/gcc)
	GNU Debugger (gdb)

At present we are building RPMs and SRPMs, as well as running the
testsuites for each project.  To begin with we are targeting
armv3l-unknown-linux-gnu, and armv4l-unknown-linux-gnu architectures for
versioned glibc hosts.  Although the source rpms should rebuild on most
Linux systems.

The files from each build are available from the web page for each
project. These include the rpms and srpms, log files of the builds, along
with the testsuite output and summaries.
	http://www.netwinder.org/build  (main project page)
	http://www.netwinder.org/build/binutils.html
	http://www.netwinder.org/build/gcc.html
	http://www.netwinder.org/build/gdb.html
	http://www.netwinder.org/build/glibc.html

	ftp://ftp.netwinder.org/pub/build/autobuild/ 
		(scripts used, poorly documented)
	http://www.netwinder.org/cvsweb/cvsweb.cgi/pub/autobuild/ 
		(scripts in CVS, usually current :))

These pages are based off similar work done by CodeSourcery,
http://www.codesourcery.com/gcc-snapshots.html for GCC targeting
i386-pc-linux-gnu.

Send any comment/suggestions to: build@netwinder.org.

The web pages were written by Ralph Siemsen and Scott Bambrough.  
Blame me for the build scripts, Rod m. Stewart.  Sponsored by 
Rebel.com, http:/www.rebel.com


For those who care: 
Warranty

	The NetWinder.Org AutoBuild system is an automated process which
runs on a daily basis. There is absolutely no quality control on these
RPMs. Use these RPMs at your own risk.

	Rebel.com and NetWinder.Org provide absolutely no warranty,
including the implied warranties of merchantability or fitness for a
particular purpose, for any code generated by the AutoBuild system.
Additionally Rebel.com and NetWinder.Org provide no support for these
RPMs. All questions regarding these RPMs, or suggestions for their
improvement should be directed to build@netwinder.org.


Enjoy,
-Rms

Re: GDB on FreeBSD/Alpha

[Andrew Cagney]

David O'Brien wrote:
> 
> On Tue, May 30, 2000 at 01:09:45AM +0200, Mark Kettenis wrote:
> > I've managed to add the necessary support for FreeBSD/Alpha to the
> > version of GDB in CVS (not checked in yet).
> 
> Hi Mark,
> 
> What version of GDB will have these bits?  5.0.1 or 5.1?  What are the
> current release engineering plans for GDB?

If it were me, I'd personally just worry about getting things in the
trunk.  For 5.0.1 (if released) I had two things in mind:

	o	fixing core dumps

	o	fixing botched configury or builds

beyond that, the trunk should be good enough. What the target
maintainers do is, well, up to target maintainers :-)

According to my diary I'm ment to make noises about 5.1 at the start of
July.  Based on what I've learnt from 5.0 that would put a release
sometime in October/November.  Exactly when is an open question.

	Andrew
From ac131313@cygnus.com Thu Jun 01 01:15:00 2000
From: Andrew Cagney <ac131313@cygnus.com>
To: Rod Stewart <stewart@netwinder.org>
Cc: gdb@sourceware.cygnus.com, build@netwinder.org
Subject: Re: [Comments?] Nightly build of GNU tool chains. (fwd)
Date: Thu, 01 Jun 2000 01:15:00 -0000
Message-id: <39361B41.401807DF@cygnus.com>
References: <Pine.LNX.4.10.10005301036440.30482-100000@kei.netwinder.org>
X-SW-Source: 2000-06/msg00001.html
Content-length: 1074

[I've pruned the cross post a little :-)]

Rod Stewart wrote:

> Send any comment/suggestions to: build@netwinder.org.

Plenty!  But first this sort of thing is very welcome.

Here are some suggested improvements to add to the end of the wish list:

Perhaps include the testsuite final numbers (pass, fail, xpass, xfail,
...) in the web page - that would allow people to quickly see trends and
pick better snapshots.

If check.log, build.log or summary.log somehow relate back to
gdb/testsuite/gdb.{sum,log} then maybe give them those names.  My first
guess was that ``build.log'' was from ``make all-gdb > build.log 2>&1''
and ``check.log'' was from ``make check-gdb > check.log 2>&1''.  Hmm,
having just downloaded ~2mb, it isn't true. Turns out that check.log
contains the contents of both sim.log + gdb.log. Could I suggest making
available:
``make all-gdb'' ``make check-gdb'' ``make check-sim'' gdb.log gdb.sum
sim.log sim.sum and those summary numbers.

BTW summary.log doesn't contain very much.

Anyway, thanks for the effort of making this all available.

	Andrew
From ac131313@cygnus.com Thu Jun 01 03:30:00 2000
From: Andrew Cagney <ac131313@cygnus.com>
To: GDB Discussion <gdb@sourceware.cygnus.com>
Subject: catch signal SIGNAL
Date: Thu, 01 Jun 2000 03:30:00 -0000
Message-id: <39363B38.305DE4CB@cygnus.com>
X-SW-Source: 2000-06/msg00002.html
Content-length: 294

Hello,

Was going through the GDB manual and noticed this feature was apparently
absent.  As a general idea, should there be a ``catch signal SIGNR''? 
Some of those hook-* may be removable with this.  Do people try to use
handle instead?

No, I'm not going to implement it myself :-)

	Andrew
From ac131313@cygnus.com Thu Jun 01 03:42:00 2000
From: Andrew Cagney <ac131313@cygnus.com>
To: robert somerville <somervil@cadvision.com>
Cc: gdb@sourceware.cygnus.com
Subject: Re: does GDB support IRIX 64 bit executables?
Date: Thu, 01 Jun 2000 03:42:00 -0000
Message-id: <39363DDA.4E64FA8C@cygnus.com>
References: <3935AC4B.12F7F004@cadvision.com> <3935B098.EAB6C771@cygnus.com> <3935CE99.CA9CC3D4@cadvision.com>
X-SW-Source: 2000-06/msg00003.html
Content-length: 1296

robert somerville wrote:
> 
> Andrew Cagney wrote:
> >
> > robert somerville wrote:
> > >
> > > especially executables produced by the MIPSpro compilers
> >
> > Um, can you be a little bit more specific?  Which ABI and native or
> > cross?  GDB internaly supports a number of MIPS ABIs, some 32 bit, some
> > 64 bit and some which are suffering an identity crisis.
> >
> >         enjoy,
> >                 Andrew
> 
> the native MIPSpro 7.3 serie\x13\x13\x13\x13s of compilers (f77/cc) in 64 bit mode (
> -64 flag )
> on R10000/R12000 chips.
> 
> I don't see a configuration option to build GDB for a 64bit enviroment,
> the default GDB build for IRIX6.5; 4.18/5.0 pukes, says
> wrong DWARF version on a 64bit executable. I suppose I could try gcc
> in 64 bit, but then f77 would be an issue for me.

I suspect it doesn't.  There is nothing in the news file.

GDB does support a number of 64 bit MIPS ABIs (eg EABI64) and that could
well be very like the ABI used by -64.  You can build a GDB supporting
these ABI's using targets like mips64-elf and mips64vr5000-elf.

Any way, I'd suggest trying to build a GDB using something like:

	CC="cc -64" ../gdb-5.0/configure
	make

This forces the IRIX 64 bit ABI to be used and hopefully that gets
things like procfs.c built using the correct headers.

	Andrew
From stewart@netwinder.org Thu Jun 01 08:20:00 2000
From: Rod Stewart <stewart@netwinder.org>
To: Andrew Cagney <ac131313@cygnus.com>
Cc: gdb@sourceware.cygnus.com, build@netwinder.org
Subject: Re: [Comments?] Nightly build of GNU tool chains. (fwd)
Date: Thu, 01 Jun 2000 08:20:00 -0000
Message-id: <Pine.LNX.4.10.10006010947420.18934-100000@kei.netwinder.org>
References: <39361B41.401807DF@cygnus.com>
X-SW-Source: 2000-06/msg00004.html
Content-length: 1598

On Thu, 1 Jun 2000, Andrew Cagney wrote:
> Rod Stewart wrote:
> 
> Here are some suggested improvements to add to the end of the wish list:
> 
> Perhaps include the testsuite final numbers (pass, fail, xpass, xfail,
> ...) in the web page - that would allow people to quickly see trends and
> pick better snapshots.

That is what is supposed to be in test summary.log, just noticed it was
broken, should be fixed on tomorrows build. :)  For projects which use
dejagnu I'm using the test_summary script from gcc/contrib to generate
this list.

> If check.log, build.log or summary.log somehow relate back to
> gdb/testsuite/gdb.{sum,log} then maybe give them those names.  My first
> guess was that ``build.log'' was from ``make all-gdb > build.log 2>&1''
> and ``check.log'' was from ``make check-gdb > check.log 2>&1''.  Hmm,
> having just downloaded ~2mb, it isn't true. Turns out that check.log
> contains the contents of both sim.log + gdb.log. Could I suggest making
> available:
> ``make all-gdb'' ``make check-gdb'' ``make check-sim'' gdb.log gdb.sum
> sim.log sim.sum and those summary numbers.

Thanks for the comments here, I'll try to make things clearer over the
weekend.

build.log currently is the output of the entire rpm build, this includes
the part from "make -k check".  I'll try to split it up a bit.

I was not aware there were two outputs, one from check-gdb, and one from
check-sim.  I'll what can be done.

> BTW summary.log doesn't contain very much.

Fixed, see above.

Thanks for the comments.

FYI, I hope to add in Linux ix86 and Linux PPC targets soon as well.

-Rms