This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: Debugging partially optimised code
- From: Robert Lupton the Good <rhl at astro dot princeton dot edu>
- To: Doug Evans <dje at google dot com>
- Cc: gdb at sourceware dot org
- Date: Mon, 20 Jun 2011 12:00:49 -0400
- Subject: Re: Debugging partially optimised code
- References: <612AB7BF-856F-4459-8DBA-D5060B4F1952@astro.princeton.edu> <BANLkTimMtdZ2scjLdortQM5TLP7AkOnkOg@mail.gmail.com>
> On Jun 14, 2011 8:01 PM, "Robert Lupton the Good" <rhl@astro.princeton.edu> wrote:
> >
> > I'm reasonably capable of debugging -O3 code, but sometimes you really want the non-optimised version. However, after recompiling just a couple of files -O0 and relinking (using g++ 4.4.6) I am having trouble.
> >
> > In particular, setting a breakpoint within the non-optimised routine results in a break in what is apparently the shared object library (!?). I didn't think that gcc did link-time optimisation (and I certainly didn't pass any -O flags to the linker). Frame 1 is OK, but frame 0 certainly isn't what I wanted; note that both SpatialModelPsf.cc and algorithmsLib_wrap.cc were compiled -O0 (although other object files in the linked libraries were linked -O3)
> >
> > Any ideas?
> >
> > (gdb) b SpatialModelPsf.cc:182
> > (gdb) f 0
> > #0 0x00002aaabe78824e in std::pair<boost::shared_ptr<lsst::afw::math::LinearCombinationKernel>, std::vector<double, std::allocator<double> > > lsst::meas::algorithms::createKernelFromPsfCandidates<float>(lsst::afw::math::SpatialCellSet const&, int, int, int, int, bool) ()
> > from /home/rhl/LSST/meas/algorithms/lib/libmeas_algorithms.so
> > (gdb) f 1
> > #1 0x00002aaabe2f7e72 in _wrap_createKernelFromPsfCandidates__SWIG_3 (args=0x25689a8)
> > at python/lsst/meas/algorithms/algorithmsLib_wrap.cc:13862
> > 13862 result = lsst::meas::algorithms::SWIGTEMPLATEDISAMBIGUATOR createKernelFromPsfCandidates< float >((lsst::afw::math::SpatialCellSet const &)*arg1,arg2,arg3,arg4,arg5,arg6);
> >
> There's perhaps too much information edited out
> (e.g. IWBN to see for myself what the output of "b SpatialModelPsf.cc:182" was),
> and I'm assuming "f 0" was done immediately after hitting the breakpoint, so guessing,
> did a breakpoint get set on an inlined copy of the requested breakpoint
> (in a file that didn't get recompiled at -O0) ?
Sorry, it's a fine balance. Yes; I set the breakpoint, then ran and the traceback was as reported.
I hadn't thought about extra inlined copies of the routine, but I don't think that that can be going on. The routine is templated, and explicitly instantiated in its .cc file --- there isn't enough information to inline the whole routine in the .h file.
R