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 Nov 26, 2012, at 9:59 PM, Stan Shebs wrote:

> ...
> 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?

That's a fair point.  If C++ makes gdbserver more maintainable or easier to improve, and those benefits outweigh the cost of dealing with space pressure for people who have it, that's a valid way to decide.  Given how C++ is "designed" it's not necessarily obvious that switching to it is a good thing, never mind that it brings benefits that outweigh the size costs, but I'll concede the possibility.

What concerned me was what seemed to be an assertion that space pressure doesn't exist.  It does and it's real, but it is indeed one factor in a set of factors that need to be traded off.
> 
> 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.

That's a very good point.

	paul


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