stabs or ecoff for Linux/mips

stabs or ecoff for Linux/mips

[H . J . Lu]

What is the better debug format for Linux/mips in the terms of gdb
and binutils, stabs or ecoff? I know the future is dwarf2. But I need
something stable now. Since Linux/x86 uses stabs, I lean toward to
stabs. Any comments?


H.J.

Re: stabs or ecoff for Linux/mips

[Daniel Berlin]

STABS definitely.

On Thu, 7 Jun 2001, H . J . Lu wrote:

> What is the better debug format for Linux/mips in the terms of gdb
> and binutils, stabs or ecoff? I know the future is dwarf2. But I need
> something stable now. Since Linux/x86 uses stabs, I lean toward to
> stabs. Any comments?
>
>
> H.J.
>

Re: stabs or ecoff for Linux/mips

[Stan Shebs]

"H . J . Lu" wrote:
> 
> What is the better debug format for Linux/mips in the terms of gdb
> and binutils, stabs or ecoff? I know the future is dwarf2. But I need
> something stable now. Since Linux/x86 uses stabs, I lean toward to
> stabs. Any comments?

Go with stabs and ELF.  Neither ecoff's base file format nor the debug
info were particularly well-documented (I remember some of the bits in
GNU being figured out by reverse engineering!), perpetuating it will
just make your life more difficult in the long run.  It will also be
easier to move to dwarf2 when the opportunity arises.

Stan

Re: stabs or ecoff for Linux/mips

[Daniel Berlin]

Stan Shebs <shebs@apple.com> writes:

> "H . J . Lu" wrote:
>> 
>> What is the better debug format for Linux/mips in the terms of gdb
>> and binutils, stabs or ecoff? I know the future is dwarf2. But I need
>> something stable now. Since Linux/x86 uses stabs, I lean toward to
>> stabs. Any comments?
> 
> Go with stabs and ELF.  Neither ecoff's base file format nor the debug
> info were particularly well-documented (I remember some of the bits in
> GNU being figured out by reverse engineering!), perpetuating it will
> just make your life more difficult in the long run.  It will also be
> easier to move to dwarf2 when the opportunity arises.

mdebugread is also an evil piece of code. 
It duplicates almost all of buildsym.  I've had to perform *major*
surgery (and am still not done yet) to do the block hash table thing.

> 
> Stan

-- 
"I looked out my apartment window, and I saw a bird wearing
sneakers and a button saying, "I ain't flying no where."  I
said, "What's your problem buddy?"  He said, "I'm sick of this
stuff -- winter here, summer there, winter here, summer there.
I don't know who thought this stuff up, but it certainly wasn't
a bird."  I said, "Well, I was just making breakfast, come on
in.  Want some eggs?  Sorry."
"-Steven Wright

Re: stabs or ecoff for Linux/mips

[H . J . Lu]

On Thu, Jun 07, 2001 at 03:05:14PM -0400, Daniel Berlin wrote:
> Stan Shebs <shebs@apple.com> writes:
> 
> > "H . J . Lu" wrote:
> >> 
> >> What is the better debug format for Linux/mips in the terms of gdb
> >> and binutils, stabs or ecoff? I know the future is dwarf2. But I need
> >> something stable now. Since Linux/x86 uses stabs, I lean toward to
> >> stabs. Any comments?
> > 
> > Go with stabs and ELF.  Neither ecoff's base file format nor the debug
> > info were particularly well-documented (I remember some of the bits in
> > GNU being figured out by reverse engineering!), perpetuating it will
> > just make your life more difficult in the long run.  It will also be
> > easier to move to dwarf2 when the opportunity arises.
> 
> mdebugread is also an evil piece of code. 

That matches my own experiences. In case you haven't noticed, I
have checked in patches to switch Linux/mips to stabs in ELF :-).


H.J.

stabs or ecoff for Linux/mips

[H . J . Lu]

What is the better debug format for Linux/mips in the terms of gdb
and binutils, stabs or ecoff? I know the future is dwarf2. But I need
something stable now. Since Linux/x86 uses stabs, I lean toward to
stabs. Any comments?


H.J.

Re: stabs or ecoff for Linux/mips

[Andrew Cagney]

dwarf2
stabs
not ecoff (er, isn't ecoff an object format like coff? I guess you mean 
something like Dwarf1)

As Dan will probably be quick to point out, you'll get better C++ 
support with dwarf2.

There is nothing unstable about dwarf2.  GDB's support for it has been 
around for yonks.

	Andrew

Re: stabs or ecoff for Linux/mips

[H . J . Lu]

On Thu, Jun 07, 2001 at 02:04:45PM -0400, Andrew Cagney wrote:
> dwarf2
> stabs
> not ecoff (er, isn't ecoff an object format like coff? I guess you mean 
> something like Dwarf1)

Ok. I meant stabs in ecoff vs. stabs in elf.

> 
> As Dan will probably be quick to point out, you'll get better C++ 
> support with dwarf2.
> 
> There is nothing unstable about dwarf2.  GDB's support for it has been 
> around for yonks.

It is more than just gdb. For a complete dwarf2 support, we need gcc
and binutils. I don't think we are there yet, at least not with stable
release.

H.J.

Re: stabs or ecoff for Linux/mips

[Ian Lance Taylor]

"H . J . Lu" <hjl@lucon.org> writes:

> On Thu, Jun 07, 2001 at 02:04:45PM -0400, Andrew Cagney wrote:
> > dwarf2
> > stabs
> > not ecoff (er, isn't ecoff an object format like coff? I guess you mean 
> > something like Dwarf1)

ECOFF is both an object file format and a debugging format.  Irix (at
least Irix 5) uses the ECOFF debugging format with the ELF object file
format (ECOFF smuggled in ELF).

The ECOFF debugging format can also be called mdebug or Third Eye, but
most people simply call it ECOFF.

Ian

Re: stabs or ecoff for Linux/mips

[Andrew Cagney]

> On Thu, Jun 07, 2001 at 02:04:45PM -0400, Andrew Cagney wrote:
> 
>> dwarf2
>> stabs
>> not ecoff (er, isn't ecoff an object format like coff? I guess you mean 
>> something like Dwarf1)
> 
> 
> Ok. I meant stabs in ecoff vs. stabs in elf.


dwarf2 in elf

Again ``There is nothing unstable about dwarf2 in elf''.


	Andrew

Re: stabs or ecoff for Linux/mips

[Bob Zulawnik]

"H . J . Lu" wrote:

> That matches my own experiences. In case you haven't noticed, I
> have checked in patches to switch Linux/mips to stabs in ELF :-).

For what it's worth : stabs format cannot express certain types
of debug info that mdebug (used in ecoff) can. An example of
that is so-called PDRs (Procedure Description Records) - they
describe frame size, register masks etc.). Thus, in order to
obtain information about a function (e.g. when setting a
breakpoint at the entrance to a function), gdb has to resort to 
heuristics and read the function prolog, trying to figure out
what registers are saved where, when is the frame setup complete
etc. There are assumptions made in that gdb code  (e.g.
mips32_heuristic_proc_desc() and mips16_heuristic_proc_desc())
that have to match exactly what the compiler has done (as in
"the occurrence of instruction 'x' signifies this"). Thus,
using the stabs opens the debugger to potential misinterpretations
of the code generated by the compiler (e.g. when a new type
of frame is introduced, or maybe with some weird optimization).
I understand that there are other arguments for using stabs and 
that dwarf2 is the long-term goal, this is just an FYI. 

Bob Zulawnik