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

Andrew Cagney
2002-09-17T18:44:57Z

> 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