Debugging partially optimised code

Debugging partially optimised code

[Robert Lupton the Good]

Dear Gdb,

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?

				R


(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);

Re: Debugging partially optimised code

[Robert Lupton the Good]

> 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

Re: Debugging partially optimised code

[Tom Tromey]

>>>>> "Robert" == Robert Lupton the Good <rhl@astro.princeton.edu> writes:

Robert> I'm reasonably capable of debugging -O3 code, but sometimes you
Robert> really want the non-optimised version.  However, after
Robert> recompiling just a couple of files -O0 and relinking (using g++
Robert> 4.4.6) I am having trouble.

Robert> In particular, setting a breakpoint within the non-optimised
Robert> routine results in a break in what is apparently the shared
Robert> object library (!?).  I didn't think that gcc did link-time
Robert> optimisation (and I certainly didn't pass any -O flags to the
Robert> linker). Frame 1 is OK, but frame 0 certainly isn't what I
Robert> wanted; note that both SpatialModelPsf.cc and
Robert> algorithmsLib_wrap.cc were compiled -O0 (although other object
Robert> files in the linked libraries were linked -O3)

Robert> Any ideas?

There isn't enough information here to go on.

The problem could range from user error (sorry) to compiler bug to gdb
bug.  It depends on various specifics that we don't know.

Tom

Re: Debugging partially optimised code

[Robert Lupton the Good]

>>> It depends on various specifics that we don't know.
> 
> Robert> OK, what can I tell you to help?
> 
> Robert> If the answer's "A reproducible test case" (always a reasonable
> Robert> request) it'll have to wait until I can find some time.
> 
> That would definitely be simplest for us.
> 
> Otherwise, if I were attacking this problem, I'd first redo my steps to
> make sure I hadn't erred; then I would look at the debuginfo for the
> library to try to understand why the breakpoint is being set there.

Any more hints on "look at the debuginfo for the library"?  The equivalent of .stabs, or something else?

					R

Re: Debugging partially optimised code

[Tom Tromey]

>>>>> "Robert" == Robert Lupton the Good <rhl@astro.princeton.edu> writes:

Tom> Otherwise, if I were attacking this problem, I'd first redo my steps to
Tom> make sure I hadn't erred; then I would look at the debuginfo for the
Tom> library to try to understand why the breakpoint is being set there.

Robert> Any more hints on "look at the debuginfo for the library"?  The
Robert> equivalent of .stabs, or something else?

Yes, I would use readelf to look at the DWARF for the library to see why
gdb thinks this line appears there.

Tom