2

I have a shared library compiled with -g -O0 including:

void MyClass::whatever()
{
  ...
  doSomething(myImage, myPoints);
  ...
}

bool MyClass::doSomething(const Image& image, std::vector<cv::Vec2f>& points) const
{ 
  const int32_t foo = 1;
  const float   bar = 0.1f;
  ...
}

Now I'm stepping through whatever() with s, but it doesn't step into doSomething(), but over it. It's not a matter of source availability, because (1) it's in the same file and (2) I can set a breakpoint in doSomething() and step there through the sources with no problem. But s seems to believe that there is no source available.

If I set step-mode on, I get output like

0xb5d51148 in myClass::doSomething (this=0xb25e4, image=..., 
points=std::vector of length -91315, capacity 372871920 = {...})
from /path/to/myclass.so

like you get when there is no source available. After a couple of n the foo initialization is displayed with source. So there could be some inline magic from my parameter (an opencv type, release build) put at the beginning of the function. Is it possible that gdb sees this stuff, thinks "weird stuff, let's continue after this function" and doesn't find that there is really source availible for most of the function?

(If should matter, it's compiled with LLVM/clang 3.5 on an ARM box with Ubuntu)

  • Do you think this question would fit better in Stackoverflow? – Philippos May 30 '17 at 10:12
1

This is likely a problem with gcc optimization and the subsequent line number table created by DWARF that maps

memory addresses that contain the executable code of a program and the source lines that correspond to these addresses

(page 8)

The simplest solution is to use stepi when the function is reached

From GDB User Manual (pg 65)

step

Continue running your program until control reaches a different source line, then stop it and return control to gdb.

....

The step command only stops at the first instruction of a source line. This pre- vents the multiple stops that could otherwise occur in switch statements, for loops, etc. step continues to stop if a function that has debugging information is called within the line. In other words, step steps inside any functions called within the line.

Also, the step command only enters a function if there is line number information for the function. Otherwise it acts like the next command. This avoids problems when using cc -gl on MIPS machines. Previously, step entered sub- routines if there was any debugging information about the routine.

  • Do you have any more details on this? – R.. Feb 22 at 19:15
  • It was a guess based on the DWARF document I linked to and how I understand step to work, in hindsight it's probably an erroneous conclusion, but I'm not sure why else gdb would step over a function that is not empty. Maybe it would have been useful to see readelf --syms a.out before jumping to conclusions. – flerb Feb 23 at 23:19

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.