Re: Bug#560786: gdb: Please make the python dependency optional
On Sun, Jan 10, 2010 at 07:06:05PM +1030, Ron wrote:
> > You've already said you don't have the space for GDB+Python. So file
> > a wishlist bug to split gdbserver out to its own package, and I'll do
> > that for you happily.
>
> I haven't seen anyone object to that idea yet, so we seem to have a
> rough consensus that would be a good plan independently of any other
> issues here, yeah.
I'm working on this. I'll see what the build time costs of a
gdb-minimal are at the same time (it's still pretty large). I still
find your arguments unconvincing, but I may as well measure the cost
of the compromise.
> > Then you don't need to put the detached debug
> > info files on your target either. If you are putting them on your
> > target, well, that explains why you can't fit GDB!
>
> "If I didn't have all that data which was actually useful to me, then
> I'd have plenty of space for whole subsystems I will never need ;?"
> That's probably not the most productive argument we could entertain :)
You can make strawman arguments at me as long as you want to. I'm
quite familiar with resource-constrained systems - I work in the
embedded industry. There are several ways to avoid keeping debug info
files on your target system, and still recover traces or conduct debug
sessions. At work, we advise all our customers to use stripped target
filesystems.
> Ok. If it's still needed, that's mostly what I was wondering.
> Surely we can also do the "takes almost no additional buildd time" trick
> with --without-python though, no? It looked like only a couple of files
> would get touched by that at all. Did I miss something there?
No, you have to reconfigure GDB from scratch to disable it. It's
probably possible to change this, but it'd be fragile; I don't think
it's a good idea.
> The range of systems is however larger than what gdbserver is suitable
> for, by its own description. Yes, it's a useful tool, for some problems,
> but it's not a magic bullet, without any cost of its own.
FYI, if you have any way to run GDB on your target, you have a way to
run gdbserver. For instance, you can multiplex it over a single
serial console. I agree there's complex setup involved.
> I have a vague sense of what you are remembering, but common sense
> should basically sum it up. Is there no way upstream would accept
> doing this as a runtime plugin, that only gets used if it's there?
I have no idea. It would be a big pain to implement.
--
Daniel Jacobowitz
CodeSourcery
Reply to: