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

[<Paul_Koning at Dell dot com>]

On Nov 26, 2012, at 8:29 PM, Stan Shebs wrote:
> ...
> People that are space-conscious are already using their own stubs or forked versions of gdbserver.  I note for instance that we nearly doubled the size of gdbserver's code when we added target-side tracepoint bits a couple years ago, and I don't recall any grousing about it getting too big then.  In a world where mega-programs like Firefox fit easily onto a cell phone *now*, I'm not just seeing that any future projects are going to be so tightly constrained that gdbserver size is noticeable.
> 
> Stan
> stan@codesourcery.com

I guess I have to keep repeating it: multi-gigabyte cell phones are NOT examples of space constrained embedded systems.  I'm working on an embedded system that's physically much larger but has only 64 MB for the program store, and only a gigabyte of memory -- of which only 128 MB is available for the OS and user mode processes.

Yes, the stock gdbserver as delivered with GBD 7 is acceptable.  No, doubling it in size is not something you can just casually propose and assume no one will object.

And I know from previous discussions that the system I'm talking about is nowhere near the most space constrained of embedded systems under active development.  So can we please stop this silly assumption that everyone has gigabytes to spare?

Yes of course, if the GDB project starts to operate on the basis that space is no object, I can and will fork.  But isn't the whole point of open source projects that, while forking is of course allowed, it isn't something to be pushed as the best way to use the project?  If forking was such a wonderful thing, we'd still have EGCS.

	paul