Christophe Hannoyer wrote:
> Hello,
> 
>> Could you do the following: put a breakpoint in your static 
>> function. When stopped there, what is IDE presenting? Then 
>> go to gdb view in IDE and type:
>>
>> (gdb) bt
>>
>> and see what is frame #0. It should be your static function.
> 
> I set a break point just before calling the "problem" function.
> The Debug view and the bt command in gdb view show the same result. The source code view show the good line and the 
Variables views the good variables.
> 
> Then I step into.
> 
> The only point which is correct now was the source code view pointing to the right line (the first line in the "
problem" function).
> 
> Debug view and dbg bt show the same stack (the same as before entering in the function, then #0 is not the "problem" 
function) and the Variables view show the caller variables.
> 
> I will try to create a specific project to reproduce the problem but it's not really easy.
> 


Thank you for clarifying. IDE and GDB show the same. I 
haven't, however, seen such a case, unless inlining is 
involved where source line may seem to jump back and forth 
between caller and inlined function definition, but stack 
frame will look as the one of the caller.

What would be interesting is to do this in your gdb view:

when you are stoped at your breakpoint (as you described 
above) type this in your gdb view:
display/i $pc

Then, instead of stepping using IDE, use gdb view and do:

stepi

multiple times, which will cause gdb to step instruction by 
insruction. Once you enter problem function, observe 
displayed program counter. Does it display PC within the 
caller's or callee range?


Thanks,

Aleksandar