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

[Daniel Jacobowitz <drow@mvista.com>]

On Tue, Sep 17, 2002 at 03:49:35PM -0400, Andrew Cagney wrote:
> >On Tue, Sep 17, 2002 at 02:44:56PM -0400, Andrew Cagney wrote:
> >
> >>
> >
> >>>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.
> >
> >
> >I think this is just as true of GDB.
> 
> Can you expand.  GCC is getting an entirely new tree representation.  I 
> don't see GDB getting anything that fundamental.

Symbol reading could use an overhaul - as Daniel likes to point out,
there's no reason to be carrying psymtabs around for DWARF-2.

Threads support is a little pulled-together under the hood - see w_f_i
and tell me it doesn't need to be redone.  A lot more of GDB's data
structures for state should be per-thread.  GDB should be properly
asynchronized so that code can run with one thread stopped without
having to force-stop all other threads; that's a horribly intrusive
wart.

I have several times mentioned my intent to overhaul the parsing of CLI
commands before the next release, if I can find a moment.  I'm doing
equally violent things to C++ although a lot of them need to wait on
improvements in symbol lookup and eventually in the DWARF-2 reader.

We can't debug inline functions much to speak of and we could; this
requires serious infrastructure changes and serious interface changes
that no one's had a chance to work on.

In even more areas, GDB is desperately need of the rewrite that parts
of GCC are getting.  We just don't have anyone willing to do them!

> >>>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.
> >
> >
> >That's not the point.  That's why I suggested a branch which does
> >require approval, precisely so that we wouldn't get into that problem.
> >But you don't seem to like that idea, so it's dead.
> 
> Me not liking an idea doesn't kill it.  It is the symtab maintainers, 
> and not me that would do the review and hence, they and not me would 
> need to be ok with it.

I was trying to suggest it as a general development practice for GDB,
but that is obviously not going to fly.  We'll have to wait for Jim or
Elena to see how it'll fly in this case.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer