Re: Move GDB to C++ ?

[Andrew Cagney <cagney at gnu dot org>]

Stan Shebs wrote:
> >   
> How can I do that meaningfully? It depends on how everything else is 
> to be designed. I'm a little surprised that you don't see it yourself, 
> actually.

I think Eli's point is reasonable, we need good reason to change the 
code; multi-arch, for instance, was motivated by the desire to support 
multiple architectures within a single GDB.  Below are two candidates 
for change; In each case they provide design suggestions that, I 
believe, are more easily expressed using an O-O paradime, and let us 
address specific limitations in the current GDB code

value has-a location has-a-multiple pieces
http://sourceware.org/ml/gdb/2008-07/msg00302.html
By breaking up value so that it's location consists of multiple pieces 
we're able to handle the modification of variables who's value is split 
between registers, or between registers and memory.  I think this 
provides an example of where we can ignore the language and focus on the 
proposed design change, deciding if it stands up on its merits.  A C++ 
implementation, while perhaps more straight forward, isn't a predicate 
to the work.

virtual stack vs physical stack
http://sourceware.org/ml/gdb/2008-07/msg00191.html
This offers both an alternative to Daniel's current inline back-trace 
code; and a way potential way forward for us to handle more complex 
unwinding such as can occure in an OpenMP program  where the user's 
stack appears to straddle multiple threads.  This design is more 
powerful in that it applies the decorator pattern; something that may be 
technically challenging in C.

For each case, especially the second, is this more straight forward in 
an O-O language, even C++.



> > > And sure, the same things could be constructed manually in C, but 
> > > then you're using piles of macro trickery a la vec.h
> > >     
> >
> > Are we still talking about ALL_OBJFILES, or about something more
> > broad?  ALL_OBJFILES is just a loop:
> >
> >     #define    ALL_OBJFILES(obj) \
> >       for ((obj) = object_files; (obj) != NULL; (obj) = (obj)->next)
> >   
> It's the the "and friends" part that is problematic, there are a dozen 
> variants at least, and the potential for doubling that number with 
> multiple execs, because sometimes you still want to iterate through 
> all indiscriminately, other times through only the objfiles for a 
> particular program. There is even a note in objfiles.h about the 
> hazards of the basic "pointer to next" approach, which was the very 
> height of C fashion twenty years ago, but is actually a chronic source 
> of bugs and memory leaks.
I'd read this more as an argument in favour of a managed runtime 
environment that included features such as garbage collection.

You're right that we need to re-think the way we allocate and manage 
memory for debug-info; determining a new global strategy for its 
management.  Once we've figured that out we can look forward to 
implementing it, and we may in deed find that the mechanisms provided by 
C++ aid in local aspects of the global strategy (we might also find that 
the complexity of C++'s features actually obscure the problem :-).  The 
thing to recognize is that C++ is a tool here, not a silver bullet.