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

Daniel Jacobowitz
2002-09-17T20:32:09Z

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