Re: Phasing out Dwarf 1?

Re: Phasing out Dwarf 1?

[Michael Elizabeth Chastain]

Hi Andrew,

> I believe that you've already demonstrated that there are no dwarf-1 
> cross compilers left (they've all migrated to dwarf-2).

I'm a bit confused by the "cross compiler" part.  For gcc I looked at
the config/ bits for all the targets without regard to hosts, so I've
always been looking at both natives and crosses.  For diab and absoft I
read their online manuals and release notes.

> That just leaves us with dwarf-1 systems.  How many dwarf-1 systems does 
> GDB still support?  If we've also eliminated all our dwarf-1 systems, 
> there's little sense in retaining dwarf-1 support.

What do you mean by 'dwarf-1 system'?  If you include systems that
support both dwarf-1 and dwarf-2, even if dwarf-1 is not the default,
then up to gcc 3.3.3, that includes most ELF-based systems.  But all
those users have upgrade paths to dwarf-2.

If you mean, 'systems where prefer dwarf-1 is the preferred debugging
format', here's a table.

  gcc 3.4.0
    none

  gcc 3.3.2
    i[34567]86-sequent-ptx4*	no longer supported by gdb
    i[34567]86-sequent-sysv4*	no longer supported by gdb
    mips-sni-sysv4		no longer supported by gdb
    sparc-hal-solaris2*		still supported by gdb (i think)

  gcc 3.2.2
    all targets from gcc 3.3.3, plus
     i[34567]86-dg-dgux*	still supported by gdb
     m88k-dg-dgux*		no longer supported by gdb

  gcc 2.95.3
    all targets from gcc 3.2.2, plus
     i[34567]86-ncr-sysv4*	still supported by gdb
     i[34567]86-*-osf1*		no longer supported by gdb
     i[34567]86-*-sco3.2v5*	still supported by gdb
     i[34567]86-*-sysv4*	still supported by gdb
     i860-alliant-*		no longer supported by gdb
     i860-*-sysv4*		no longer supported by gdb
     m68k-atari-sysv4*		no longer supported by gdb
     m68k-cbm-sysv4*		no longer supported by gdb
     m68k-*-sysv4*		no longer supported by gdb
     m88k-*-sysv4*		no longer supported by gdb
     mips-*-gnu*		no longer supported by gdb
     sh-*-elf*			still supported by gdb
     sh-*-rtemself*		still supported by gdb
     sparc-*-sysv4*		still supported by gdb

That's just gcc.  It doesn't include systems with non-gcc compilers
that still emit dwarf-1.  I don't know if any such systems exist.

So if somebody has an i386-dg-dgux system, they could still be
using gcc 3.2.2 and dwarf-1.  Or i686-unknown-sco3.2v5 and
gcc 2.95.3.  Or sparc-*-sysv4* and gcc 2.95.3.

I'm not sure what the thrust of your question is so I don't know
if this is the info that you're looking for.

Michael C

Re: Phasing out Dwarf 1?

[Andrew Cagney]

> That's just gcc.  It doesn't include systems with non-gcc compilers
> that still emit dwarf-1.  I don't know if any such systems exist.

If you installed operating system X, including the vendor compiler, and 
typed `cc -g ..` would the debug format be dwarf-1?

Of those, how many do we still support.

> So if somebody has an i386-dg-dgux system, they could still be
> using gcc 3.2.2 and dwarf-1.  Or i686-unknown-sco3.2v5 and
> gcc 2.95.3.  Or sparc-*-sysv4* and gcc 2.95.3.
>
> I'm not sure what the thrust of your question is so I don't know
> if this is the info that you're looking for.

Andrew

Re: Phasing out Dwarf 1?

[Kean Johnston]

> If you installed operating system X, including the vendor compiler, and 
> typed `cc -g ..` would the debug format be dwarf-1?
> 
> Of those, how many do we still support.
At least 3 I know of: SCO, UnixWare ans Solaris x86. DG-UX may as well,
but I cant swear to its native debugging format. I wish I could say
I will have the energy and time to maintain this in gdb but I just
cant say that. Id be far more interested in getting it doing correct
stack traces in 6.1 on SCO than in supporting DWARF1. SCO for one
provides a 'sanctioned' version of gdb, which is 5.1, which does
support DWARF1, and I will continue to provide it if it gets phased
out of the mainline, I would just prefer not to if its reasonably
possible. Since only relatively uncommon platforms are likely to
be affected by this and given the burden of maintaining it I can see
why you want to drop it. I really dont mind providing two versions
of gdb if I have to.

Kean

Re: Phasing out Dwarf 1?

[Stan Shebs]

Kean Johnston wrote:

>> If you installed operating system X, including the vendor compiler, 
>> and typed `cc -g ..` would the debug format be dwarf-1?
>>
>> Of those, how many do we still support.
>
> At least 3 I know of: SCO, UnixWare ans Solaris x86. DG-UX may as well,
> but I cant swear to its native debugging format. I wish I could say
> I will have the energy and time to maintain this in gdb but I just
> cant say that. Id be far more interested in getting it doing correct
> stack traces in 6.1 on SCO than in supporting DWARF1.

This confuses me a bit - what debugging format would you use
if Dwarf 1 were no longer available?

Stan

Re: Phasing out Dwarf 1?

[Kean Johnston]

> This confuses me a bit - what debugging format would you use
> if Dwarf 1 were no longer available?
I would have no choice but to either:
1) Change to a compiler that produced DWARF-2 or
2) Use an older version of GDB that supports DWARF-1.

Both are reasonable choices for most people, the second being
the least disruptive.

Kean

Re: Phasing out Dwarf 1?

[Michael Elizabeth Chastain]

For gdb 6.1, I get some noise, but the backtrace looks okay:

  (top-gdb) backtrace
  #0  captured_main (data=0xbffff690) at /tmp/chastain/d1/gdb-6.1/gdb/main.c:117
  During symbol reading, DIE @ 0x1df "interpreter_p", type modifier 'const' ignored.
  During symbol reading, DIE @ 0x1d25 "", array subscript format 0x1 not handled yet.
  During symbol reading, DIE @ 0x14d7d "pthread_spinlock_t", type modifier 'volatile' ignored.
  #1  0x08080321 in do_catch_errors (uiout=0x82b72a0, data=0xbffff648)
      at /tmp/chastain/d1/gdb-6.1/gdb/top.c:523
  #2  0x08080124 in catcher (func=0x8080305 <do_catch_errors>,
      func_uiout=0x82b72a0, func_args=0xbffff648, func_val=0xbffff654,
      func_caught=0xbffff650, errstring=0x822a7c8 "", gdberrmsg=0x0, mask=6)
      at /tmp/chastain/d1/gdb-6.1/gdb/top.c:430
  #3  0x0808035c in catch_errors (func=0x807aa66 <captured_main>,
      func_args=0xbffff690, errstring=0x822a7c8 "", mask=6)
      at /tmp/chastain/d1/gdb-6.1/gdb/top.c:535
  #4  0x0807b87a in gdb_main (args=0xbffff690)
      at /tmp/chastain/d1/gdb-6.1/gdb/main.c:814
  #5  0x0807aa21 in main (argc=1, argv=0xbffff734)
      at /tmp/chastain/d1/gdb-6.1/gdb/gdb.c:35

This is on a native i686-pc-linux-gnu, red hat enterprise linux 3,
gdb compiled with gcc 3.2.3-24-rh.  "make CFLAGS=-gdwarf"

I get similar three messages "During symbol reading ..." with gdb 6.0
operating on gdb 6.0, and also gdb 5.3 operating on gdb 5.3.

> What are the results if the testsuite is run?

I already posted this link from February 2003:

  http://sources.redhat.com/ml/gdb-patches/2003-02/msg00293.html

I will do it again with gdb 6.1 but it will take some time.

> Or to look at it another way, when was the last time (other than SCO's 
> 5.1) that anyone saw a working dwarf-1 GDB?

It looks like gdb is working, with some glitches, and the test suite
has been busted for a while.

Michael C

Re: Phasing out Dwarf 1?

[Andrew Cagney]

> This is on a native i686-pc-linux-gnu, red hat enterprise linux 3,
> gdb compiled with gcc 3.2.3-24-rh.  "make CFLAGS=-gdwarf"

I was thinking more of GDB against the SCO system compiler.

Andrew

Re: Phasing out Dwarf 1?

[Michael Elizabeth Chastain]

Kean Johnston writes:
> At least 3 I know of: SCO, UnixWare ans Solaris x86. DG-UX may as well,
> but I cant swear to its native debugging format.

OpenServer and UnixWare:
  AFAIK, it's still FSF's policy to support SCO's platforms.  I disagree
  with this policy but if dwarf-1 is needed for OpenServer and UnixWare
  then gdb has to keep supporting dwarf-1.

Solaris X86:
  Mark, can you say anything about this?  What debug format does "cc -g"
  produce on a solaris x86 machine?

DG-UX:
  I looked into this in February 2003.  Takis Psarogiannakopoulus
  developed a native toolchain for this platform based on dwarf-2.
  Takis said that his port is based on dwarf-2.  More importantly,
  Takis said that the FSF version of gdb has *never* worked on dg-ux
  (his emphasis) and might as well just be removed.

    http://sources.redhat.com/ml/gdb/2003-02/msg00074.html

  The FSF sent Takis a copyright assignment.  I don't know if he
  executed it or not, but he balked at getting a disclaimer from
  his employer.  And nobody has done any work to merge Takis's
  work back into FSF gdb.

  Since last year, EMC (the owner of Data General) has put all
  their web pages for dg-ux support behind a login barrier and
  requires a support contract to read them.  So I can't say what
  has happened with dg-ux lately.  As of 2003-02, the most recent
  version of dg-ux was DG/UX 4.20MU07, released 2001-04.

Michael C

Re: Phasing out Dwarf 1?

[Andrew Cagney]

> Kean Johnston writes:
> 
>>> At least 3 I know of: SCO, UnixWare ans Solaris x86. DG-UX may as well,
>>> but I cant swear to its native debugging format.
> 
> 
> OpenServer and UnixWare:

Given GDB 5.3, 6.0 and 6.1, and:

	$ ./configure
	$ make
	$ ./gdb/gdb ./gdb/gdb
	(gdb) b captured_main
	(gdb) run
	(gdb) bt

what happens?  What are the results if the testsuite is run?

Or to look at it another way, when was the last time (other than SCO's 
5.1) that anyone saw a working dwarf-1 GDB?

Andrew

Re: Phasing out Dwarf 1?

[Mark Kettenis]

   Date: Wed,  5 May 2004 18:01:32 -0400 (EDT)
   From: mec.gnu@mindspring.com (Michael Elizabeth Chastain)

   Solaris X86:
     Mark, can you say anything about this?  What debug format does "cc -g"
     produce on a solaris x86 machine?

Not really.  The OS doesn't come with a bundled compiler.  So I only
use GCC.  Sun's unbundled compiler on SPARC uses stabs by default,
although there is an option to generate dwarf.  I don't know whether
that's DWARF 1 or 2.  There seems to be some evidence that it's DWARF
2.  I think dropping support for DWARF 1 is acceptable for
i[3-7]86-*-solaris2*.

Mark

Re: Phasing out Dwarf 1?

[Michael Elizabeth Chastain]

Andrew Cagney writes:
> If you installed operating system X, including the vendor compiler, and 
> typed `cc -g ..` would the debug format be dwarf-1?
> 
> Of those, how many do we still support.

It's kinda difficult to answer any question about "for all operating
system X ...".  I don't know!

For the question "for all operating system X such that gdb HEAD has
configuration machinery", someone could in principle answer that
question by checking all the systems in configure.host.  However we
don't even check that all those systems build before releasing gdb (or,
if someone does check, nobody publishes a report on gdb@ or gdb-testers@
about it).  I don't know how many of the systems in configure.host
come with a non-gcc vendor compiler that emits dwarf-1.

For the question "for all operating system X such that someone has
mailed a test report to gdb-testers about that OS in the past N years",
I could research that.  But it would take a lot of time, and I'd rather
drop my proposal and keep dwarf-1 as-is until somebody draws up an
explicit list of supported operating systems and compilers for gdb.

Michael C

Re: Phasing out Dwarf 1?

[Michael Elizabeth Chastain]

Stan Shebs writes:
> But how is it going to get tested? Experience shows that untested parts
> of GDB bitrot pretty quickly, and without any volunteers to let us know
> when things break and/or fix them when they do, the claim of support
> is just misleading to users.

On this subject, the last time I tried dwarf-1 with the gdb test suite,
I got 46 ERROR, 39 UNRESOLVED, and 3463 FAIL.  This was in February 2003.

  http://sources.redhat.com/ml/gdb-patches/2003-02/msg00293.html

IIRC, the test suite took about nine hours to run, compared to fifteen
minutes for dwarf-2 or stabs+.

I don't know if this is systemic failure in the test suite or
systemic failure in gdb.

Michael C

Phasing out Dwarf 1?

[Michael Elizabeth Chastain]

I would like to phase out support for the Dwarf 1 debug format.

I did some research and wrote the results as comments in dwarfread.c.
I found reports from gdb users with three different compilers mentioned:

  gcc
  diab
  absoft

All of these compilers now have released versions with dwarf-2 support.
gcc 3.4.0 has no more dwarf-1 at all.

My idea is to ask the steering committee to adopt a roadmap for
phasing out Dwarf 1 support.

What do you think?

Michael C

Re: Phasing out Dwarf 1?

[Andrew Cagney]

> I would like to phase out support for the Dwarf 1 debug format.
> 
> I did some research and wrote the results as comments in dwarfread.c.
> I found reports from gdb users with three different compilers mentioned:
> 
>   gcc
>   diab
>   absoft

I believe that you've already demonstrated that there are no dwarf-1 
cross compilers left (they've all migrated to dwarf-2).

That just leaves us with dwarf-1 systems.  How many dwarf-1 systems does 
GDB still support?  If we've also eliminated all our dwarf-1 systems, 
there's little sense in retaining dwarf-1 support.

(we might also determine that such systems require an ISO-C compiler 
(e.g., GCC) to build GDB and hence argue that GDB can assume dwarf-2 is 
present.)

> All of these compilers now have released versions with dwarf-2 support.
> gcc 3.4.0 has no more dwarf-1 at all.

For the moment lets get the technical argument straight.

Andrew

Re: Phasing out Dwarf 1?

[Nathan J. Williams]

Andrew Cagney <cagney@gnu.org> writes:

> (we might also determine that such systems require an ISO-C compiler
> (e.g., GCC) to build GDB and hence argue that GDB can assume dwarf-2
> is present.)

This seems like a poor argument. The availibility and suitability of
modern GCC for building GDB does not imply that modern GCC will be
suitable for building the application to be debugged.

        - Nathan

Re: Phasing out Dwarf 1?

[Kean Johnston]

> This seems like a poor argument. The availibility and suitability of
> modern GCC for building GDB does not imply that modern GCC will be
> suitable for building the application to be debugged.

I agree. I think phasing out a whole debugging format
is ill-advised. Most people dont want to keep around
multiple versions of a tool. If I need to debug an
old binary becuase the libc I replaced today is breaking
something, I think I have a reasonable expectation of
being able to do so. I think it is quite appropriate to
phase out the *generation* of said format, but not its
interpretation in a debugger.

Kean

Re: Phasing out Dwarf 1?

[Stan Shebs]

Kean Johnston wrote:

>> This seems like a poor argument. The availibility and suitability of
>> modern GCC for building GDB does not imply that modern GCC will be
>> suitable for building the application to be debugged.
>
>
> I agree. I think phasing out a whole debugging format
> is ill-advised. Most people dont want to keep around
> multiple versions of a tool. If I need to debug an
> old binary becuase the libc I replaced today is breaking
> something, I think I have a reasonable expectation of
> being able to do so. I think it is quite appropriate to
> phase out the *generation* of said format, but not its
> interpretation in a debugger.
>
> Kean
>
But how is it going to get tested? Experience shows that untested parts
of GDB bitrot pretty quickly, and without any volunteers to let us know
when things break and/or fix them when they do, the claim of support
is just misleading to users. There are many previous releases of GDB
that do include Dwarf 1 support, and they build/run fine on a wide
variety of hosts, so it's not like Dwarf 1 users are being left
debugger-less.

Now if you're going to volunteer to set up a Dwarf 1 testing
regimen with an old GCC and current GDB, and report on it
regularly, I think that could justify keeping it. But miss
a week, and poof! :-)

Stan

Re: Phasing out Dwarf 1?

[Jim Blandy]

Kean Johnston <jkj@sco.com> writes:
> > This seems like a poor argument. The availibility and suitability of
> > modern GCC for building GDB does not imply that modern GCC will be
> > suitable for building the application to be debugged.
> 
> I agree. I think phasing out a whole debugging format
> is ill-advised. Most people dont want to keep around
> multiple versions of a tool. If I need to debug an
> old binary becuase the libc I replaced today is breaking
> something, I think I have a reasonable expectation of
> being able to do so. I think it is quite appropriate to
> phase out the *generation* of said format, but not its
> interpretation in a debugger.

You're assuming it's basically free to keep Dwarf 1 support in GDB.  I
don't think that's the case.

If someone wants to work on the interfaces the debug readers use to
the format-independent portion of GDB, then the Dwarf 1 reader is one
more client of those interfaces to take into account.

If you look in the ChangeLogs, you can see that dwarfread.c continues
to require periodic tweaks.  But these are almost all mechanical
changes that somebody found by 'grep', or things the compiler caught.
How many bugs have been introduced by semantic shifts elsewhere in GDB
that the compiler has been unable to detect?  I'll bet there are a
lot.  In these circumstances, it seems like wishful thinking to say
that GDB supports Dwarf 1.

I would be happy if either:

- a volunteer were to adopt the Dwarf 1 reader, test it regularly
  against any compiler (GCC or otherwise), and work on reducing the
  number of test suite failures it has over the more actively
  maintained readers, or

- we were to delete the Dwarf 1 reader, and make it that much easier
  for people to do symtab work.

But to leave the code there, with no active volunteers to keep it
useful, is the worst of both worlds.

Re: Phasing out Dwarf 1?

[Andrew Cagney]

> Andrew Cagney <cagney@gnu.org> writes:
> 
> 
>>> (we might also determine that such systems require an ISO-C compiler
>>> (e.g., GCC) to build GDB and hence argue that GDB can assume dwarf-2
>>> is present.)
> 
> 
> This seems like a poor argument. The availibility and suitability of
> modern GCC for building GDB does not imply that modern GCC will be
> suitable for building the application to be debugged.

For the systems of concern here they have old compilers, and equally old 
shipped debuggers.  While a current GDB might work in theory, in reality 
it just isn't worth the effort of finding out - remember step-1 is 
somehow build/test an ISO-C compiler.

Andrew