Why isn't GDB designed and implemented by using Object-Oriented methodology?

Why isn't GDB designed and implemented by using Object-Oriented methodology?

[xingxing pan]

When meeting so many structs and function pointer in the source codes,
dose anyone have the thought to redesign and implement GDB using
Object-Oriented  methodology?
Since one of the debugger's functions is to slow down the execution of
the debugee, implementing GDB by using Object-Oriented  language will
not observably affect the performance.

Open Source is a good idea. But it seems open the process of design is
much more important. After all, the development of a software is a
process, not just only a result presented by the source codes.With the
source codes, one can hardly see the design process.

Re: Why isn't GDB designed and implemented by using Object-Oriented methodology?

[Jan Kratochvil]

On Wed, 16 Jun 2010 13:54:16 +0200, xingxing pan wrote:
> When meeting so many structs and function pointer in the source codes,
> dose anyone have the thought to redesign and implement GDB using
> Object-Oriented  methodology?

See the last discussion:
	Move GDB to C++ ?
	http://sourceware.org/ml/gdb/2008-07/msg00077.html
	http://sourceware.org/ml/gdb/2008-08/msg00004.html

There is an ongoing work to make it at least possible:
	http://sourceware.org/gdb/wiki/ArcherBranchManagement
		-> archer-ratmice-compile-Wc++-compat

This idea is not new.


Thanks,
Jan

Re: Why isn't GDB designed and implemented by using Object-Oriented methodology?

[Joel Brobecker]

> > When meeting so many structs and function pointer in the source codes,
> > dose anyone have the thought to redesign and implement GDB using
> > Object-Oriented  methodology?
> 
> See the last discussion:
> 	Move GDB to C++ ?
> 	http://sourceware.org/ml/gdb/2008-07/msg00077.html
> 	http://sourceware.org/ml/gdb/2008-08/msg00004.html

One can develop software using "Object Oriented *methodology*" without
using a language that implements classes. An object is, at its simplest,
data and methods. If you are using the term "methodology" to actually
mean "language", then indeed, as Jan points out, this is not a new
discussion.  Despite my strong reservations about moving away from C,
I have no doubt in my mind that we will eventually be moving GDB
development to C++.  But in the meantime, some parts of GDB already have
an OO aspect to them.

-- 
Joel

Re: Why isn't GDB designed and implemented by using Object-Oriented methodology?

[Stan Shebs]

xingxing pan wrote:
> When meeting so many structs and function pointer in the source codes,
> dose anyone have the thought to redesign and implement GDB using
> Object-Oriented  methodology?
>   

Well, the target vector abstraction dates from 1990, so that means we've 
been redesigning GDB to use object-oriented methodology for the past 
twenty years or so.

In practice, the hard part for us is deciding what the objects *should* 
be.  If someone posted a mega-patch tomorrow that converted GDB to C++ 
written in good style, that wouldn't do a thing to help me figure out 
how to support changing properties of tracepoints while a trace is 
running, or how to speed up symbol reading for really large executables, 
or how to reliably install software breakpoints with the inferior 
running in a non-stop mode.

So yes, more OOM "would be nice" and we encourage the submission of 
patches going in that direction, but it's not the magic bullet that will 
magically make GDB easy to work on.

Stan

Re: Why isn't GDB designed and implemented by using Object-Oriented methodology?

[Robert Dewar]

Joel Brobecker wrote:
>>> When meeting so many structs and function pointer in the source codes,
>>> dose anyone have the thought to redesign and implement GDB using
>>> Object-Oriented  methodology?
>> See the last discussion:
>> 	Move GDB to C++ ?
>> 	http://sourceware.org/ml/gdb/2008-07/msg00077.html
>> 	http://sourceware.org/ml/gdb/2008-08/msg00004.html
> 
> One can develop software using "Object Oriented *methodology*" without
> using a language that implements classes. An object is, at its simplest,
> data and methods. 

Interesting to see this definition take hold, very different from
the classical (e.g. Simula) view of objects. To me data+methods =
abstract data type.

Re: Why isn't GDB designed and implemented by using Object-Oriented methodology?

[xingxing pan]

Actually, what I want to say is that coding is different from design.

2010/6/17 Robert Dewar <dewar@adacore.com>:
> Joel Brobecker wrote:
>>>>
>>>> When meeting so many structs and function pointer in the source codes,
>>>> dose anyone have the thought to redesign and implement GDB using
>>>> Object-Oriented  methodology?
>>>
>>> See the last discussion:
>>>        Move GDB to C++ ?
>>>        http://sourceware.org/ml/gdb/2008-07/msg00077.html
>>>        http://sourceware.org/ml/gdb/2008-08/msg00004.html
>>
>> One can develop software using "Object Oriented *methodology*" without
>> using a language that implements classes. An object is, at its simplest,
>> data and methods.
>
> Interesting to see this definition take hold, very different from
> the classical (e.g. Simula) view of objects. To me data+methods =
> abstract data type.
>

Re: Why isn't GDB designed and implemented by using Object-Oriented methodology?

[Tom Tromey]

>>>>> "xingxing" == xingxing pan <forandom@gmail.com> writes:

>> Actually, what I want to say is that coding is different from design.

Much of GDB actually is written in an object-oriented style.
In some cases the expression of the underlying design is odd.

It would be helpful if you were more specific.  What exactly do you
think could be improved?

We're also happy to review cleanup patches :-)

Tom