This is the mail archive of the archer@sourceware.org mailing list for the Archer 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: [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
version skew.

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
is everything.

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

-- 
Daniel Jacobowitz
CodeSourcery


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