Re: Deprecate dwarf and mdebug support, delete nlm?

[Daniel Berlin <dberlin@dberlin.org>]

On Sunday, May 4, 2003, at 02:10  AM, Michael Elizabeth Chastain wrote:

> I've been waiting for DWARF 1 to come up.  Here are some random facts:
>
> I've run the test suite with -gdwarf and -gdwarf+.  My results were
> 40+ ERRORs and 3400+ FAILs.
>
> In gcc 3.2.2, these targets prefer DWARF 1:
>
>   i[34567]86-dg-dgux*
>   i[34567]86-sequent-ptx4*
>   i[34567]86-sequent-sysv4*
This was scheduled to be obsoleted in 3.1, actually, I don't knwo what 
held it up.
Quote a former member of sequent's compiler group (Janis Johnson):

"On Mon, Apr 15, 2002 at 10:05:42AM -0700, Zack Weinberg wrote:
 >
 > There are a LOT of weird proprietary-Unix m68k and i386 ports.  Would
 > someone more familiar with the history care to look through this list
 > and suggest more culls?
 >
 >       i?86-sequent-sysv3*
 >       i?86-sequent-sysv4*
 >         i?86-sequent-bsd*
 >         i?86-sequent-ptx1*
 >         i?86-sequent-ptx2*

These can probably all be dropped.  Most of them are for operating
systems that Sequent stopped supporting many years ago.  The most
recent, ptx2, wasn't upgraded for Y2K changes and hasn't been
supported since."

These weren't removed in 3.1 for no reason that i can tell (probably 
forgot), since nobody said to keep them.

*All* the sequent targets (not just those in the email above) are 
scheduled to go in 3.3.

>   m88k-dg-dgux*
>   mips-sni-sysv4
>   sparc-hal-solaris2*
All of these are scheduled for deprecation in 3.3, which means nobody 
has been maintaining them for *quite* a while.

> <2.95> list omitted

If you guys want to support something because 2.95 does, feel free, but 
realize that the gcc team (me included) will close bug reports against 
2.95.x where it's been fixed in a later version.
So if you find some DWARF1 generation bug fixed between 2.95.x and now, 
the only options gdb has are either to work around it (thus increasing 
the burden of maintaining DWARF 1), or to mark it as wontfix.

So i don't really see the point here in caring about targets on 
branches that are guaranteed to never see another release.



> The real hang-up is non-gcc compilers that emit DWARF 1.

It's not like DWARF-2 (or even STABS) is all that *new*.
If we were talking about vendors only having a year or two to have 
added support for DWARF-2 that's one thing.
But at this point, do you really think the remaining DWARF 1 only 
vendors are going to up and decide it's a good idea for them to *ever* 
move off DWARF 1 unless something drastic happens?
Like say their GDB using customers who now can't use new GDB's threaten 
to switch to another compiler (since there aren't that many debuggers 
out there)?
It could be a good thing too, if they switch to using free software 
like gcc because the vendor decides not to support anything but DWARF 
1, customers be damned.

Then again, this is probably just your typical "I'm doing this for your 
own damn good, you just don't know it yet, you should thank me" 
bullshit. :P

Besides that, whether or not some non-free compiler emits DWARF 1 is 
irrelevant to supporting DWARF 1 in gdb. We don't care about non-free 
compilers, remember?

If it's a burden to gdb to maintain, remove it.
If it's not, keep it.


>
> I recall seeing two instances of that in bug reports in the past year,
> but I don't have URL's handy.
>
> Michael C