Re: GDB is the GNU project's native debugger

[Andrew Cagney <cagney at gnu dot org>]

> > It's a complex problem and as such has middle ground and negotiation
> > dependant on the scale of the work:
> >
> > - Corinna recently changed an architecture interface and, since it was
> > straight forward, did the 'busywork'.
> >
> > - The frame code, on the other hand, was anything but straight
> > forward, it instead started with a single architecture and then
> > expanded as back end maintainers did their (much appreciated) stuff.
> > In the end though, a long list of architectures were simply deleted
> > (should I have instead done the 'busywork' of frameifying the ns32k?).
> >
> > Perhaps you can expand on your point by explaining where you would
> > strike up the balance for making an invasive change such as
> > asynchronous native (proc, ptrace) support.  GDB has many many
> > non-async embedded targets, but only two natives.  Should we predicate
> > the work on the modification of all the embedded inferiors?  Or should
> > we accept that the work is so key to GDB's future as a native that we
> > can tolerate a few short term problems?
>
>
> I think that in general you expanded on my point better than I could.
> As you say, it's a complex problem.  You are proposing a simple
> principle, and my concern is that once such a thing is adopted it will
> be used to enforce simplistic solutions to complex problems.  As I
> said before, the principle itself seems unobjectionable in many
> contexts.  My concern is that it will be applied in cases where it is
> too simple.

> Or, to put it another way: why do we need an overly simple statement
> about what we agree is a complex issue?

My post has context.  I've recently encountered situtations where 
developers were insisting that I test my changes on ULTRIX; or that I 
seek approval when making trivial and pre-announced changes.

As such we all need a reality check.  Remind ourselves what the overall 
objective here is; and against what baseline we should each measure our 
requests.

> 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.

I think it is first important to recognize that the pressure placed on 
GDB is different to that encountered by other members of the toolchain - 
binutils and gcc.  GCC, for instance, has a simple pipeline 
architecture: FRONTEND <tree> MIDDLEEND ... <tree> BACKEND.  Individual 
FRONT, MIDDLE and BACK ends can largely be developed in isolation, and 
plugged in and out at will.   Only when the <tree> is changed, as 
occurred when moving from RTL to SSA, to things get scary and slow 
careful engineering processes (as again applied to SSA) are required.

Contrast that to GDB, where underlying the architecture is a relatively 
complex web of objects (there's an O-O model fighting to get out of the 
C code :-).   When developing such a model a key process has to be 
refactoring the code - modifying the object model (changing 
relationships and interfaces) so that the next change can be 
accommodated - and a key attribute of refactoring is that each has a 
short cycle: taking days, and not years to complete.

If we look over GDB's [short list of not so] recent core changes, we 
find that for the true inovations such as:

- multi-arch started '98, not finished
- frames started dec? '02, finished nov '04
- event-loop started '98, finished jun? '04
- regcache started dec? '02, not finished

the innovator did (I pushed through 3/4 of the above) implement backward 
compatibility so that out-of-date systems were given an opportunity to 
update and consequently waited-a-year or more.  When we examine how each 
of these changes panned out, though - the extra year makes no 
difference.  Only when compatibility code starts to be removed (or I 
stand my ground and require an update as an predicate to another 
contributions) that we see activity to revive out of out-of-date systems 
(and then only for a limited set).

You make the assertion:

> A clean and elegant program is a goal, but it is not the only goal.

We're not talking here about clean or elegant code.  Rather we're 
discussing GDB's backlog of refactorings (struct value, struct location, 
struct symbol, ...); each made of many smaller changes; each 
establishing another part of a robust OO model; each dependant on 
earlier work; each ensuring a more maintainable code base; and most 
importantly each a prereq to adding advanced features to gdb.

Such refactorings need to be performed in time periods that amount to 
weeks, and not the months or years we currently see.

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

Andrew