This is the mail archive of the
mailing list for the Archer project.
Re: [patch] Fix glitches with libstdc++ pretty printers
On Fri, Oct 31, 2008 at 11:53:33AM -0600, Tom Tromey wrote:
> Yeah, this is the same problem as header-only libraries -- there is no
> separate objfile.
> My current thinking is that this is the application author's problem.
> That is, when doing the static-link-equivalent is also the best place
> to note the dependencies.
> There are some python-script management problems here, but nothing too
> outrageous. I think it can mostly be boiled down to: if you ship a
> static library, you should also ship the .py.
> Then at link time the application Makefile could also dig around for
> .py scripts and concatenate them into a new one for the application.
I don't think that's good enough. We need to have some way for GDB to
collect and manage these automatically, even if it doesn't handle
For example, I'm going to ship a packaged arm-none-eabi toolchain that
includes libstdc++.a and libstdc++-gdb.py. If we have to complicate
the IDE builder, and tell our users to complicate their build process,
no one's going to get the spiffy pretty printers. Automation really
> Daniel> I did like Jan's idea of matching the debug file search. That
> Daniel> lets us keep GDB files outside of /usr/lib directly.
> We get this for free, because we do the same loading for the objfile
> that is created when gdb reads the separate debug info.
> For Fedora I think we may pull the .py files into the separate debug
> RPMs automatically. Though, I am not completely sure -- it seems to
> me that perhaps users would want to pretty-print libstdc++ containers
> without necessarily installing all of its debug info.
You've just contradicted yourself in these two statements. If we
don't have the debug info, would we still look for .debug/*-gdb.py?