Re: Move GDB to C++ ?

[Vladimir Prus <vladimir@codesourcery.com>]

Andrew Cagney wrote:

> Vladimir Prus wrote:
>> Andrew Cagney wrote:
>>
>>   
>>> Instead of changing GDB to C++ and hoping the change will magically
>>> transform GDB's code base into a clean ideal design; should we instead
>>> be focused on trying to address what I suspect is the underlying
>>> motivation here - a desire to clean up and re-structure GDB's code base
>>> so that it more clearly corresponds to a more modern Object Oriented design?
>>>     
>>
>> I think that trying to use better design without support of a language for which
>> such design is a native one, would be considerably harder. GNOME is a perfect
>> example -- in attempt to use OOP in C, they have this GObject thing which is an
>> approximation of real classes, only harder to use. Ah, and there's even separate
>> tool, called GOP, that takes class definition in some meta-language and produces
>> .h and .c file. So, there's fairly complicate non-standard solution for
>> an already-solved problem.
>>   
> 
> The question I'm asking here is are we focusing on C++ as a solution,
> and mistakenly trying to rely on its features as a solution, when we
> should instead be first focusing on the design, what ever the
> implementation language?
> 
>> Let's use one example in GDB -- values. Presently, struct value has a
>> field lval_type, and in a number of places, a switch over lval_type is
>> made. This switch-over-type is a typical red-flag in OOP programs; in case
>> of GDB this makes it hard to understand what is exact behaviour of
>> lval_register, for example. CodeSourcery's implementation of register browing
>> required extending struct value, so that fetching a value goes via special
>> remote protocol packet. This ended up been not exactly nice. If struct value
>> was a base class with a defined interface, and each kind of value (rvalue, lvalue,
>> register, etc) were a derived class, then the internal logic of GDB would be
>> more clear, and adding new kinds of values would be much simpler.
>>   
> 
> For instance, an alternative value relationship we've seen proposed:
> 
>      value
>          has-a type
>          has-a location
> 
>      location
>          has-a 1:N piece
> 
>     piece
>         is-a memory piece
>         is-a register piece
>         is-a constant piece
> 
> (credit to tthomas for this refined design) which removes gdb's
> limitation of a value having a single [register] location.  This is a
> design alternative, not an implementation alternative.  Once we've
> concurred on the design we can implement it using language-of-the-day.
> 
> If, in attempting to make these changes we find that the C
> implementation truly cumbersome then we've a compelling story for
> language change.    This is assuming that the intent here is find ways
> to allow greater architectural reform in GDB (and a language change is
> just an aid to that goal).  You seem to at least be agreeing with this?

The intent, at least for me, is to be more productive hacking on GDB. One
approach to that goal is replacing emulation of classes and exceptions with
native language constructs. Another approach is to change internal architecture.
And when changing internal architecture, it's desirable to have the help of 
implementation language.

We already have existing architecture that works, and the implementation is
truly cumbersome in my opinion. So why spend even more time first
redesigning bits of GDB, then implementing new design in C, and then decide
that, oh, yes, this is truly truly cumbersome.

- Volodya