This is the mail archive of the gdb@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Will therefore GDB utilize C++ or not?


On 04/13/2012 01:04 AM, Doug Evans wrote:

> On Thu, Apr 12, 2012 at 1:06 PM, Daniel Jacobowitz
> <daniel.jacobowitz@gmail.com> wrote:
>> The more things we add to gdbserver, the less I think it meets the
>> goal of "simple, light-weight target agent".  I resisted code sharing
>> with GDB for a long time.  If the consensus nowadays is that code
>> sharing is the way to go, then I think it behooves someone to figure
>> out the needs of a modern light-weight target agent that's a lot
>> smaller than gdbserver.
>>
>> Yes, multiprocess debugging with gdbserver is an awesome development.
>> No, you don't need it in the stage of system bringup where you don't
>> have C++, if you're planning to have C++ eventually.  So I think
>> there's room for a potential C++ gdbserver and a small C gdbserver.
> 
> [filing for reference sake]
> 
> I'd (ultimately) like to see gdb and gdbserver built up out of a set
> of, umm, libraries ("We need more libraries!").


I'm aiming torwards making the gdbserver backends be a library that
is reused by both gdb and gdbserver.  Gotta start somewhere.

> Exporting the functionality of the libraries to scripting languages
> (e.g., python) through these libraries would involve more of a C API
> than C++.
> 
> With said partitioning of functionality, it shouldn't be that hard to
> have either a small and simple gdbserver or a large and feature-rich
> gdbserver.


Exactly.

-- 
Pedro Alves


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]