Re: GDB on FreeBSD/Alpha

[Mark Kettenis <kettenis@wins.uva.nl>]

   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