This is the mail archive of the gdb@sourceware.cygnus.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

RE: GDB on FreeBSD/Alpha


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

Unless stabs-in-ecoff is a completely different format, you are right.
GCC knows how to output dwarf2,dwarf,stabs, and a few others.

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

Dunno.
I'm in this for the later questions
:)
>
> > 	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?
I can tell you once it gets there.

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

Here's where i come in.
I wouldn't argue against it.
> Wouldn't it be better for FreeBSD/Alpha
> to stay with stabs, in particular to maintain uniformity with
> FreeBSD/i386?
No, it wouldn't.
In fact, FreeBSD/i386 should move to DWARF2 as well.

> 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 are the advantages of DWARF2 versus stabs?

STABS just wasn't made to do what it's being hacked around to do right now.
Fer instance, C++ support in stabs really just isn't there in GDB.
The fact that operator overloading works at all in stabs+gdb, is due to a
hack.
DWARF2 has clear technical superiority over STABS, though STABS has more
political clout, and more implementations.
The STABS implementation in gcc is more mature than the dwarf2
implementation.
In fact, DWARF2 even allows for debugging of frame-pointerless code, though
we don't grok the unwind info yet (it's on my list).
As you can imagine, C++ in gdb works about 50x better with dwarf2 than with
stabs in actuality. Things like inline functions, etc, work properly in
DWARF2, and don't in stabs.
So, in simple terms, dwarf2 is just much more flexible than stabs.
If you need to do C++ at all, i would really go with DWARF2, the more that
do, the sooner i don't have to deal with bug reports of bugs that just work
when you use DWARF2, and I have to hack around in GDB to make work with
STABS.

--Dan




Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]