Re: Deprecate dwarf and mdebug support, delete nlm?

Re: Deprecate dwarf and mdebug support, delete nlm?

[Andrew Cagney]

Just FYI, it's dead code elimination, and not the desire to save a few 
extra bytes, that is the motivating force behind this discussion.

GDB is always looking to remove code that:

- is not used
- is out-of-date

Out-of-date code (relying on almost defunct interfaces) is always a problem.

Andrew

>> Ok, so nlm/ is a candidate (but it isn't hurting anyone, and 
> 
> I cant believe that you all here are talking about a ./nlm subdir of 86.3kB while the whole gdb source is more than 14MB !! And that all at times where download bandwidth isnt an issue anymore!
> 

RE: Deprecate dwarf and mdebug support, delete nlm?

[Kean Johnston]

Hi,

I admit I missed the first part of this thread so if this is off
base, ignore me. SCO still uses DWARF and gdb is about the only
decent debugger available. I'd hate to see DWARF go.

Kean

Re: Deprecate dwarf and mdebug support, delete nlm?

[Eli Zaretskii]

> Date: Fri, 09 May 2003 12:48:51 -0400
> From: Andrew Cagney <ac131313@redhat.com>
> 
> > mec> Are there still a lot of SCO users with gcc 2?
> > kj> HUGE numbers. It's the currently "officially supported" version
> > kj> that we give our customers. Until 3.3 we haven't really felt GCC
> > kj> 3 was ready for primetime. In fact the next "oficially supported"
> > kj> version will be 3.4.
> 
> > Okay, that means we have to keep dwarf 1 for another 6-12 months
> > at least.  Rats.
> 
> I don't know ....

My vote is to retain DWARF 1 until SCO switches to GCC 3.x as their
official version.  I think otherwise we would be unfairly punishing
SCO users.  I agree with Kean that a solid compiler is much more
important that a debugger, so most users will not upgrade GCC just
because GDB wants them to.  OTOH, those SCO users who do use GDB
should be able to benefit from the new GDB features.

> Yes.  There is no such thing as free beer.  Someone, eventually, ends up 
> paying for it.

Let's ask the SCO developers to pay at least part of that price.  In
fact, Kean already volunteered, so that issue appears to be taken care
of.

> This has come up before.  The GDB 4 to 5 transition occured due to a 
> switch to ISO C.  People with a K&R compiler needing to either download 
> GCC, or GDB 4.x.

That's a totally different beer ;-) The compiler used to build GDB is
not teh same as the compiler used to build production software.  One
could install a newer GCC, compile GDB, and then use the older GCC for
development.  Or one could download binary packages of GDB someone
else built.  It's much easier to solve this kind of problems than the
one SCO users will face if we drop DWARF 1 now.

Re: Deprecate dwarf and mdebug support, delete nlm?

[Andrew Cagney]

> It's a resource issue.  As Andrew Cagney has said, it takes 
> 
> I'll help out if I can :)

Does anyone have a list of specific requirements?

The one I know about is how that DWARF enters block information into the 
symbol table (but I don't know the details).

Andrew

Re: Deprecate dwarf and mdebug support, delete nlm?

[Andrew Cagney]

> mec> Are there still a lot of SCO users with gcc 2?
> kj> HUGE numbers. It's the currently "officially supported" version
> kj> that we give our customers. Until 3.3 we haven't really felt GCC
> kj> 3 was ready for primetime. In fact the next "oficially supported"
> kj> version will be 3.4.

> Okay, that means we have to keep dwarf 1 for another 6-12 months
> at least.  Rats.

I don't know ....

> kj> Aside from that ... just as a general guiding light, a debugger
> kj> shouldn't be target to a compiler, that's bad practice. It should
> kj> take advantage of features of the compiler if it can but it should
> kj> be VERY forgiving of things like debug formats (ie support as many
> kj> as it can), calling conventions etc.
> 
> It's a resource issue.  As Andrew Cagney has said, it takes work to keep
> all the debug format readers current with the symbol table infrastructure,
> and gdb has limited resources available.

Yes.  There is no such thing as free beer.  Someone, eventually, ends up 
paying for it.

The active GDB developers have reached the point where they are paying 
dearly for the retention of a very out-of-date debug module.

This has come up before.  The GDB 4 to 5 transition occured due to a 
switch to ISO C.  People with a K&R compiler needing to either download 
GCC, or GDB 4.x.  I'm struggling to see a reason for not making a 
similar transition here.  DWARF users need to either update their GCC, 
or download a GDB 5 series debugger.

Andrew

RE: Deprecate dwarf and mdebug support, delete nlm?

[Kean Johnston]

> It's a resource issue.  As Andrew Cagney has said, it takes 
I'll help out if I can :)

Kean

RE: Deprecate dwarf and mdebug support, delete nlm?

[Michael Elizabeth Chastain]

mec> Are there still a lot of SCO users with gcc 2?
kj> HUGE numbers. It's the currently "officially supported" version
kj> that we give our customers. Until 3.3 we haven't really felt GCC
kj> 3 was ready for primetime. In fact the next "oficially supported"
kj> version will be 3.4.

Okay, that means we have to keep dwarf 1 for another 6-12 months
at least.  Rats.

kj> Aside from that ... just as a general guiding light, a debugger
kj> shouldn't be target to a compiler, that's bad practice. It should
kj> take advantage of features of the compiler if it can but it should
kj> be VERY forgiving of things like debug formats (ie support as many
kj> as it can), calling conventions etc.

It's a resource issue.  As Andrew Cagney has said, it takes work to keep
all the debug format readers current with the symbol table infrastructure,
and gdb has limited resources available.

Michael C

RE: Deprecate dwarf and mdebug support, delete nlm?

[Kean Johnston]

> The SCO target is i[34567]86-*-sco3.2v5*.
> 
> With gcc 2.95.3, this target prefers DWARF 1 or SDB.
> 
> With gcc 3.2.2, this target prefers DWARF 2 or SDB.
> (see config.gcc and config/i386/sco5.h in the source).
Yeah I know I'm the maintainer :)

> Are there still a lot of SCO users with gcc 2?
HUGE numbers. It's the currently "officially supported" version
that we give our customers. Until 3.3 we haven't really felt GCC
3 was ready for primetime. In fact the next "oficially supported"
version will be 3.4.

> If there are, is it reasonable to require them to upgrade to gcc 3
> when they upgrade their gdb?
Not really. For one, more people compile than debug (sad but true)
so it is much more critical that the compiler works, and once people
have a stable, working compiler they are VERY loathsome to switch.
But a debugger is considered more of a utility tool and people are
more prone to update it (and to be frank, as the integrator of our
'GNU tools' package I am more likely to WANT to update it). There
are other good improvements in GDB that even current consumers can
benefit from.

Aside from that ... just as a general guiding light, a debugger
shouldn't be target to a compiler, that's bad practice. It should
take advantage of features of the compiler if it can but it should
be VERY forgiving of things like debug formats (ie support as many
as it can), calling conventions etc.

Kean

RE: Deprecate dwarf and mdebug support, delete nlm?

[Michael Elizabeth Chastain]

The SCO target is i[34567]86-*-sco3.2v5*.

With gcc 2.95.3, this target prefers DWARF 1 or SDB.

With gcc 3.2.2, this target prefers DWARF 2 or SDB.
(see config.gcc and config/i386/sco5.h in the source).

Are there still a lot of SCO users with gcc 2?

If there are, is it reasonable to require them to upgrade to gcc 3
when they upgrade their gdb?

(The proposal is to phase out DWARF 1 only.  DWARF 2 is one of the best,
most current formats).

Michael C

Re: Deprecate dwarf and mdebug support, delete nlm?

[Armin Diehl]

I think the gdbserve is a candidate for deletion. It is only needed for 
netware 3.11 and prevents building gdb with netware support. I always 
have to remove that dir in the configure targets file.
My gdb2ndi works with netware 4.11 also (load rdebug.nlm). If someone 
needs the gdbserve for 3.11, it can be used from older versions of gdb. 
(It is only a simple support for the gdb remote protocol)

But please please *do not remove* the netware support from gdb. It is 
the only way to debug FreePascal nlm's.
It is further needed for debugging nlms generated by gcc. Bernd Herd has 
done a great job in porting gcc with c++ support to netware and it would 
be bad if we loose the debugging support as we now have a great 
alternative c/c++ compiler for netware.


Günter Knauf wrote:

> Hi Andrew,
> 
>>Ok, so nlm/ is a candidate (but it isn't hurting anyone, and 
> 
> I cant believe that you all here are talking about a ./nlm subdir of 86.3kB while the whole gdb source is more than 14MB !! And that all at times where download bandwidth isnt an issue anymore!
> 
> 
>>the alternative is written in FreePascal :-). 
> 
> that's only true for NetWare 5.1 and 6, but with previous versions we still need the gdbserver!
> 
> 
>>Andrew
> 
> 
> removing 86.3kB isnt worth to talk about! Just my 2 ct.
> 
> but if you are searching for the last few bytes for deleting, just take 10,9kB and remove ./nlm/ppc.h and ./nlm/ppc.c because I dont know of any NetWare version which runs on PPC; all versions for which gdbserver is of interest run on i386!
> 
> thanks, Guenter.
> 

Re: Deprecate dwarf and mdebug support, delete nlm?

[Elena Zannoni]

Ulrich Neumann writes:
 > Hello,
 > 
 > please do not drop NLM Support. Several people at Novell just
 > started with GCC as one of the supported development
 > environments and we're working on getting a lot of GNU
 > applications like gcc, bash, binutils as well as other nice tools
 > like gdb... running on NetWare.
 > 

This is great news.

 > It is our plan to give every change and every enhancement
 > back to you, the community.
 > 

excellent

 > I'm sure you will see much more activity around NLM
 > development with GNU tools in a few months because of the
 > work we're currently doing.
 > 

Make sure you have copyright assignments in place, before you send
patches, please. In the meantime, you should feel free to use this
community as a forum for exchanging ideas and discussing future
development plans. Doing so will definitely help with the integration
of your contributions.

thanks
Elena


 > Thank you
 > 
 > Ulrich Neumann
 > Novell DeveloperNet SysOp
 > Worldwide Novell Developer Support

Re: Deprecate dwarf and mdebug support, delete nlm?

[Elena Zannoni]

=?ISO-8859-1?Q?G=FCnter_Knauf?= writes:
 > Hi Elena,
 > > nlm... you mean nlmread.c or nlm/* ?
 > > google threw up a few things:
 > > http://home.arcor.de/armin.diehl/fpcnw/gdbnw.html (seems active, uses 5.3).
 > > http://www.herdsoft.com/ti/netware/cross/4_Debugging.html
 > > There is a gdb wrapper program now that translated netware remote
 > > protocol into gdb remote protocol and vice versa. So they are not
 > > using NLM gdbserver anymore because that supports older versins of
 > > netware only.
 > 
 > > elena
 > 
 > please dont do that!! We still need the NLM gdbserver; 
 > a few NetWare developers (including me) started about 4 years ago with 
 > developing NLMs with gcc/nlmconv, and also we use the gdbserver. I know
 > both of the above mentioned developers and I'm in contact with them;
 > and if we really dont need the gdbserver anymore we will post here...
 > but until then please dont drop the NLM support!
 > thanks, Guenter.
 > 

Ah, there is life out there, then! :-) This is good news. Let me
explain: the problem we are facing is that gdb is moving forward,
while a few pieces, like nlm, mdebug support, etc, seem to languish
behind, and don't get modernized as the rest of gdb.  It is becoming
harder and harder to keep them integrated with the rest of the
debugger, mostly because people don't have a way to even test them.

Given that there is active development in this area, I strongly
encourage you and the other Netware developers to become an active
part of the gdb community, and bring the parts you work on more in
tune with the rest of the debugger. We will all benefit from such an
approach.

Are you guys willing to do that? If so, please, make sure you have
copyright assignments in place ahead of time.

TIA
Elena

Re: Deprecate dwarf and mdebug support, delete nlm?

[Günter Knauf]

Hi Andrew,
> Ok, so nlm/ is a candidate (but it isn't hurting anyone, and 
I cant believe that you all here are talking about a ./nlm subdir of 86.3kB while the whole gdb source is more than 14MB !! And that all at times where download bandwidth isnt an issue anymore!

> the alternative is written in FreePascal :-). 
that's only true for NetWare 5.1 and 6, but with previous versions we still need the gdbserver!

> Andrew

removing 86.3kB isnt worth to talk about! Just my 2 ct.

but if you are searching for the last few bytes for deleting, just take 10,9kB and remove ./nlm/ppc.h and ./nlm/ppc.c because I dont know of any NetWare version which runs on PPC; all versions for which gdbserver is of interest run on i386!

thanks, Guenter.

Re: Deprecate dwarf and mdebug support, delete nlm?

[Ulrich Neumann]

Hello,

please do not drop NLM Support. Several people at Novell just
started with GCC as one of the supported development
environments and we're working on getting a lot of GNU
applications like gcc, bash, binutils as well as other nice tools
like gdb... running on NetWare.

It is our plan to give every change and every enhancement
back to you, the community.

I'm sure you will see much more activity around NLM
development with GNU tools in a few months because of the
work we're currently doing.

Thank you

Ulrich Neumann
Novell DeveloperNet SysOp
Worldwide Novell Developer Support

Re: Deprecate dwarf and mdebug support, delete nlm?

[Günter Knauf]

Hi Elena,
> nlm... you mean nlmread.c or nlm/* ?
> google threw up a few things:
> http://home.arcor.de/armin.diehl/fpcnw/gdbnw.html (seems active, uses 5.3).
> http://www.herdsoft.com/ti/netware/cross/4_Debugging.html
> There is a gdb wrapper program now that translated netware remote
> protocol into gdb remote protocol and vice versa. So they are not
> using NLM gdbserver anymore because that supports older versins of
> netware only.

> elena

please dont do that!! We still need the NLM gdbserver; 
a few NetWare developers (including me) started about 4 years ago with 
developing NLMs with gcc/nlmconv, and also we use the gdbserver. I know
both of the above mentioned developers and I'm in contact with them;
and if we really dont need the gdbserver anymore we will post here...
but until then please dont drop the NLM support!
thanks, Guenter.

Re: Deprecate dwarf and mdebug support, delete nlm?

[Daniel Berlin]

On Monday, May 5, 2003, at 01:30  PM, Andrew Cagney wrote:

>> I don't think its a fair measure to equate number of  patches with 
>> value.
>
> The number of patches does at least hint at the level of activity.  As 
> for value, part of a value judgment is determining the cost.
>
>> I've still got users who are using commercial compilers that emit 
>> dwarf1 and
>> it would be a great loss to these users if dwarf1 went away.
>
> Significant structural change, such as adding support for multiple 
> address spaces, moves more rapidly when there are fewer debug readers 
> to content with.

I think the real problem isn't the number of debug readers, but in the 
particular implementations of these two debug readers.  IE The problem 
with these two debug readers is precisely that *because* nobody has 
ever maintained or updated them, anyone wanting to improve our debug 
reading in general by changing structures or whatnot, has to contend 
with the old, obsolete, and sometimes non-existent methods these 2 
readers use to build the various data structures gdb uses.
Had they kept up with the passage of time, i don't think we'd be 
considering obsoleting them, because they wouldn't be in the way.  They 
are so far past bit-rotted that they have evolved into their own 
obscure species.

> These users potential loss is someone elses potential gain.  These 
> users can also continue to use an existing GDB.
>
> As someone (michael?) suggested, can these users move to Free 
> compilers?
Nope, it was me who made the suggestion.
The other possibility I mentioned is that the vendor in question will 
wake up and implement a debug format from the past decade (DWARF 2.0 
standard was published July 27th, 1993).

Re: Deprecate dwarf and mdebug support, delete nlm?

[Andrew Cagney]

> Andrew Cagney writes:
>  > Deprecate dwarf and mdebug support, delete nlm?
>  > .
>  > .
> 
> deprecate Dwarf1
> 
> Not yet for mdebug, maybe mention something about it being queued for
> deprecation in the NEWS/TODO file for the next release?

If True64 uses mdebug, I might have access to a machine.  Damd!

> nlm... you mean nlmread.c or nlm/* ?

`yes' (I was actually thinking of nlmread.c, but hey why not nlm/* as 
well ...).

> google threw up a few things:
> http://home.arcor.de/armin.diehl/fpcnw/gdbnw.html (seems active, uses 5.3).
> http://www.herdsoft.com/ti/netware/cross/4_Debugging.html
> There is a gdb wrapper program now that translated netware remote
> protocol into gdb remote protocol and vice versa. So they are not
> using NLM gdbserver anymore because that supports older versins of
> netware only.

Ok, so nlm/ is a candidate (but it isn't hurting anyone, and the 
alternative is written in FreePascal :-).  The reader, though, appears 
to be stuck-in-the-mud (like DWARF).

Andrew

Re: Deprecate dwarf and mdebug support, delete nlm?

[Andrew Cagney]

> I don't think its a fair measure to equate number of  patches with value.

The number of patches does at least hint at the level of activity.  As 
for value, part of a value judgment is determining the cost.

> I've still got users who are using commercial compilers that emit dwarf1 and
> it would be a great loss to these users if dwarf1 went away.

Significant structural change, such as adding support for multiple 
address spaces, moves more rapidly when there are fewer debug readers to 
content with.  These users potential loss is someone elses potential 
gain.  These users can also continue to use an existing GDB.

As someone (michael?) suggested, can these users move to Free compilers?

>> Here is the URL for one guy who has a diab compiler and wanted
>> to improve gdb dwarf-1 support:
>> 
>>   http://sources.redhat.com/ml/gdb-patches/2002-07/msg00505.html
>> 
>> That's the extent of interest in dwarf-1: two people in the past year
>> with diab compiler: this guy, and one other that I didn't dig up
>> the URL for yet.

Andrew

Re: Deprecate dwarf and mdebug support, delete nlm?

[Jim Blandy]

Andrew Cagney <ac131313@redhat.com> writes:
> Deprecate dwarf and mdebug support, delete nlm?

I don't think there'll be a problem with Dwarf 1 going.  I do seem to
remember working with mdebug more recently, so I'm less sure about
that.

If we do deprecate these things, I think GDB should squawk whenever it
sees them.  I think the lesson to be learned from the "annotation
level two" story is that simply putting an item in NEWS isn't enough
to get people to warn us if they're unhappy about a deprecation.

Perhaps, even after support for those formats is removed, GDB should
continue to print a message like, "This executable file contains some
debugging information in the Dwarf 1 format, which GDB is no longer
able to read."

Re: Deprecate dwarf and mdebug support, delete nlm?

[Tim Combs]

I don't think its a fair measure to equate number of  patches with value.
I've still got users who are using commercial compilers that emit dwarf1 and
it would be a great loss to these users if dwarf1 went away.

Tim
> Here is the URL for one guy who has a diab compiler and wanted
> to improve gdb dwarf-1 support:
> 
>   http://sources.redhat.com/ml/gdb-patches/2002-07/msg00505.html
> 
> That's the extent of interest in dwarf-1: two people in the past year
> with diab compiler: this guy, and one other that I didn't dig up
> the URL for yet.
> 
> Michael C

Re: Deprecate dwarf and mdebug support, delete nlm?

[Joel Brobecker]

> Deprecate dwarf and mdebug support, delete nlm?

We are still using the Tru64 port, which is depending on mdebug. Could
we keep it, please?

-- 
Joel

Re: Deprecate dwarf and mdebug support, delete nlm?

[Andrew Cagney]

Which reminds me, can I encourage people to use dwarf2 as the prefix 
(functions, variables, filenames) for stuff that is DWARF 2 specific. 
GDB is hopelessly inconsistent :-(

Andrew
(Mark you just reminded me of dwarf2expr, dwarf2cfi and even dwarf2read :-)

Re: Deprecate dwarf and mdebug support, delete nlm?

[Elena Zannoni]

Andrew Cagney writes:
 > Deprecate dwarf and mdebug support, delete nlm?
 > .
 > .

deprecate Dwarf1

Not yet for mdebug, maybe mention something about it being queued for
deprecation in the NEWS/TODO file for the next release?

nlm... you mean nlmread.c or nlm/* ?
google threw up a few things:
http://home.arcor.de/armin.diehl/fpcnw/gdbnw.html (seems active, uses 5.3).
http://www.herdsoft.com/ti/netware/cross/4_Debugging.html
There is a gdb wrapper program now that translated netware remote
protocol into gdb remote protocol and vice versa. So they are not
using NLM gdbserver anymore because that supports older versins of
netware only.

elena


 > .
 > Any one even got an idea as to the consequences?
 > 
 > Andrew

Re: Deprecate dwarf and mdebug support, delete nlm?

[Michael Elizabeth Chastain]

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

If I recall correctly, the i*86-sequent-ptx4* configuration was
reprieved because some poeple said they were actually using it.
And then it came back onto an obsoletion list later and didn't
get reprieved.  That matches what you are saying.

But that's pretty vague in my mind.  I need to dive into the archives
some more.

The older configurations like i*86-sequent-ptx2* were killed.

db> If you guys want to support something because 2.95 does, feel free, but 
db> realize that the gcc team (me included) will close bug reports against 
db> 2.95.x where it's been fixed in a later version.

Right.  Some users are stuck with gcc 2.95.3.  As a gdb guy, I would
like everybody to upgrade to most recent gdb, even people who are
stuck with gcc 2.95.3.

I am in favor of obsoleting DWARF 1 support.  But if we don't do it
right now, it will continue to get easier in the future.  Gcc keeps
dropping the dwarf-1 configurations for us, which is cool.

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

In general, I personally care about interoperating with non-free software
whenever it helps gdb build market share.

In this case, I think that gdb would not lose much market share,
and it's useful to kill off a whole symtab reader.

Here is the URL for one guy who has a diab compiler and wanted
to improve gdb dwarf-1 support:

  http://sources.redhat.com/ml/gdb-patches/2002-07/msg00505.html

That's the extent of interest in dwarf-1: two people in the past year
with diab compiler: this guy, and one other that I didn't dig up
the URL for yet.

Michael C

Re: Deprecate dwarf and mdebug support, delete nlm?

[Daniel Jacobowitz]

On Sun, May 04, 2003 at 12:41:29AM -0400, Andrew Cagney wrote:
> Deprecate dwarf and mdebug support, delete nlm?
> .
> .
> .
> Any one even got an idea as to the consequences?

dwarf:

We got a bug report (with patch, that I need to look at...) for a Diab
compiler that emits DWARF 1.  There are still widely used DWARF
hardware debuggers, too - not a big deal for us, just a reference
point.

I'd say deprecate it.


mdebug:
Joel's been actively fixing bugs in this as I recall.  Tru64 uses it. 
I don't think we can do that just yet.


nlm:
Just make it go away...

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: Deprecate dwarf and mdebug support, delete nlm?

[Daniel Berlin]

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

Re: Deprecate dwarf and mdebug support, delete nlm?

[Michael Elizabeth Chastain]

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*
  m88k-dg-dgux*
  mips-sni-sysv4
  sparc-hal-solaris2*

I also have a list for gcc 2.95.3, which is quite a bit longer.

  i[34567]86-dg-dgux*
  i[34567]86-ncr-sysv4*
  i[34567]86-sequent-ptx4*
  i[34567]86-sequent-sysv4*
  i[34567]86-*-osf1*
  i[34567]86-*-sco3.2v5*
  i[34567]86-*-sysv4*
  i860-alliant-*
  i860-*-sysv4*
  m68k-atari-sysv4*
  m68k-cbm-sysv4*
  m68k-*-sysv4*
  m88k-dg-dgux*
  m88k-*-sysv4*
  mips-sni-sysv4
  mips-*-gnu*
  sh-*-elf*
  sh-*-rtemself*
  sparc-hal-solaris2*
  sparc-*-sysv4*

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

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

Michael C

Deprecate dwarf and mdebug support, delete nlm?

[Andrew Cagney]

Deprecate dwarf and mdebug support, delete nlm?
.
.
.
Any one even got an idea as to the consequences?

Andrew