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

[Daniel Berlin <dberlin@dberlin.org>]

On Tuesday, September 17, 2002, at 02:44  PM, 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.
This is mistaken.
Not that GCC doesn't need things completely replaced, but that GDB is 
fine. It's symbol table, debug info reader, location evaluation, etc, 
needs some of its fundamental data structures and algorithms completely 
replaced.
I'd agree that the non-debug info related architecture is fine (IE 
multiarch and whatnot), excluding the way threads are handled.

But both GCC and GDB have these problems for the same reasons:
They were not designed to handle the complexities that they are now 
required to handle.
The scale up in terms of project size has been absurd in the past few 
years.
GCC has resigned itself to deal with these cases.
GDB has ignored them for the past few years, because nobody has had the 
time to do the replacements of algorithms and data structures, to 
handle things like namespaces, etc.
This doesn't, however, mean it doesn't need to be done.
--Dan