Re: [RFA] convert blocks to dictionaries, phase 1, main part

[Andrew Cagney <ac131313 at ges dot redhat dot com>]

> Basically, at any point when you don't have a lot of temporary gunk.  I
> confess, I'm of two minds about working on a branch for this sort of thing:
> I consider it very impractical for things which don't break up into
> pieces easily afterwards.  GCC has been using an interesting approach,
> which I think we could adapt and extend here.
GCC's approach relies on GCC's development cycle: break, fix, release. 
You can only pull stuff in from those branches during the ``break'' 
phase.  And during that phase, things, from what I've seen, really are 
broken (I got stuck trying to commit a patch because I couldn't 
build/test GCC for several weeks).

I also, to be honest, think that GCC has bigger problems than GDB.  With 
GDB, the basic architecture is fine (if you look at the relationships 
and ignore all the globals and messed up interfaces :-).  GCC, on the 
other hand, needs some of its fundamental data structures and algorithms 
completly replaced.

> How about a branch which require approval just like the mainline for
> large patches, although giving David a little more freedom to play
> around.  Then, we'd allow large merges from the branch back to the
> trunk when they were ready and tested - larger patches than we'd
> normally accept all at once, because they'd already been approved.
>
> Andrew - thoughts?  Does it have any interesting possibilities?
Let me put it this way, I'm scared shitless of another HP jumbo patch.

For GDB, I think change comes in two forms:

- external / structural / interface
- internal

Internal interfaces are the ones that can easily be broken down.  Since 
everything is hidden behind an interface nothing needs to know what 
happend (just as long as it still works :-).

External / structural / interface changes are harder.  For these, I 
think (based on regcache and reggroup) there can be several changes:

- proof of concept using a branch

I think each branch should be for a single experiment -> no approval 
required but all patches should be posted so everyone can see what is 
going down (and if they like point out problems).  The purpose being to 
explore the idea and figure out exactly what the interfaces should look 
like.  (See regcache branch where I changed the interface several times 
and now that its on the mainline, the interface is still evolving.)

While playing, you'll always identify stuff that can be immediatly 
pushed into the trunk.  The MIPS generic dummy frames pulled out a 
number of things that needed fixing.

- interface changes

Using the knowledge gained, implement a new interface, possibly 
implemented using existing structures.  This is often just big and 
mechanical.

Here, for instance, I think all the existing queries are based around 
``struct block''.  Abstract them and then, behind the scenes 
re-implement the underlying structure so that it does what it is really 
ment to do -- return the correct symbol given a block.

- change internals

Which would fill in the missing bits.  This and the interface changes 
often alternate (and occasionally there is a very large lumpy patch :-)

.

Branches, however, do also involve great risk.  Since there isn't that 
pressure to get things into the trunk, it is too easy to become 
defocused and change everything else and ignore the objective.

enjoy,
Andrew