Re: GDB on FreeBSD/Alpha

[Mark Kettenis <kettenis at wins dot uva dot 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