Re: GDB is the GNU project's native debugger

[Ian Lance Taylor <ian at airs dot com>]

Andrew Cagney <cagney@gnu.org> writes:

> > On your specific issue, I think that async native support would
> > require either a flag day or supporting two separate interfaces for
> > some time.  A flag day is only acceptable if all major architectures
> > can be converted simultaneously.  Off the cuff I would say that
> > supporting two separate interfaces would have to last for at least a
> > year.  Yes, this is hard.  Yes, it leads to more duplicated work.  A
> > clean and elegant program is a goal, but it is not the only goal.
> 
> I waited a year, and nothing happened.

Personally, I would say that after a year you can go ahead and break
the code which has not been updated.

This doesn't necessarily mean that you should delete it immediately
(although of course it can be retrieved from CVS).  Just break it.

I don't know whether gcc has a notion of "primary platforms," as gcc
does.  I suppose that it would not be acceptable to break a primary
platform.

> Is such a rate of change possible if we're required to constantly
> schedule flag days, or wait for a year?

First, I'll note that if you provide a backward compatibility
interface, then the fact that some ports have not been updated does
not prevent you from continuing to work.

Second, what is your alternative?  If your alternative is to cause gdb
to not work on many popular platforms, then I suspect that is a false
choice.  In the long run the effect will be to lose users and
developers.  That is only acceptable if you are willing and able to be
the sole developer of gdb.  If not, then you must accomodate other
people and their schedules.

(Being the only developer may not be absurd.  For a couple of years I
was essentially the only developer of the binutils--other people
contributed target specific ports, but I wrote or rewrote every
significant change to the internals.  But the binutils are much
simpler than gdb.)

Ian