gdb não entra em função embora a fonte esteja disponível

Question

Eu tenho uma biblioteca compartilhada compilada com -g -O0 , incluindo:

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;
  ...
}

Agora estou passando por whatever() com s , mas não entra em doSomething() , mas sim em cima. Não é uma questão de disponibilidade de fontes, porque (1) está no mesmo arquivo e (2) eu posso definir um ponto de interrupção em doSomething() e passar pelas fontes sem nenhum problema. Mas s parece acreditar que não há fonte disponível.

Se eu set step-mode on , recebo saída como

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

como acontece quando não há fonte disponível. Após alguns n , a inicialização foo é exibida com a origem. Portanto, pode haver algum inline magic do meu parâmetro (um opencv type, release build) colocado no início da função. É possível que gdb veja essas coisas, pense em "coisas estranhas, vamos continuar depois dessa função" e não acha que existe realmente uma fonte disponível para a maior parte da função?

(Se deve importar, é compilado com o LLVM / clang 3.5 em uma caixa ARM com o Ubuntu)

    

Answer 1

Este é provavelmente um problema com a otimização do gcc e a subseqüente tabela de números de linha criada por DWARF que mapeia

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

(page 8)

A solução mais simples é usar stepi quando a função é alcançada

Em Manual do usuário do GDB (página 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.