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: Debugging partially optimised code


> 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


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