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
    Commented May 30, 2017 at 10:12

1 Answer 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)


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? Commented Feb 22, 2019 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
    Commented Feb 23, 2019 at 23:19

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .