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

[Stan Shebs <stanshebs@earthlink.net>]

On 11/26/12 6:02 PM, Paul_Koning@Dell.com wrote:
> 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
>

The flipside is that you're potentially making everybody else work 
harder for your sake.  If you're the only one with a space-constrained 
target using stock gdbserver, then it might make more sense to look into 
tweaking a C++ gdbserver to stay under the size you require.  For 
instance, when we discussed this before, 300K was OK for space, so 
presumably 600K is not good - perhaps just conditionalize the tracepoint 
bits to compensate for the space lost to C++ runtime?

It's always seemed a little sloppy to me that we advertise gdbserver as 
suitable for targets, but don't actually track its size, consider each 
patch's effect, etc.  For instance, a one-liner that brings in a bunch 
of library code might be more problematic for footprint than a page of 
new code.

Stan
stan@codesourcery.com