Why does gdb stop at a different line than “i b” shows while returning from function?

Why does gdb stop at a different line than “i b” shows while returning from function?

[wempwer]

Here is the program I am trying to debug:

#include <stdio.h>
int i = 5;

int main(void)
{
    int x = 3;

    display(x);
    return 0;
}


void display(int x)
{
for ( i=0; i<x; ++i ) {
    printf("i is %d.\n", i);
}
}


This code is coming from here http://www.dirac.org/linux/gdb/05-Stepping_And_Resuming.php#breakpointsandwatchpoints26. Here is the problem:

(gdb) break display 
Breakpoint 1 at 0x40051e: file try5.c, line 15.
(gdb) run
Starting program: /home/ja/gdb/learning/try5 

Breakpoint 1, display (x=3) at try5.c:15
(gdb) frame 1
#1  0x000000000040050c in main () at try5.c:8
(gdb) break 
Breakpoint 2 at 0x40050c: file try5.c, line 8.
(gdb) c
Continuing.
i is 0.
i is 1.
i is 2.

Breakpoint 2, main () at try5.c:9
(gdb) i b
Num     Type           Disp Enb Address            What
1       breakpoint     keep y   0x000000000040051e in display at try5.c:15
    breakpoint already hit 1 time
2       breakpoint     keep y   0x000000000040050c in main at try5.c:8
    breakpoint already hit 1 time
(gdb) c
Continuing.

Program exited normally.
(gdb) q

Debugger finished


It was supposed to stop at line 8 in main() but it stopped at line 9 it main(). For me it's misleading. I think it should stop at line 9, because this is what 'break' commands does - sets a break point at the very next instruction. But why "info breakpoints" said that the break point was set at line 8?

Re: Why does gdb stop at a different line than “i b” shows while returning from function?

[Joachim Protze]

[-- Attachment #1: Type: text/plain, Size: 1006 bytes --]

On 29.07.2012 20:54, wempwer@gmail.com wrote:
> Here is the program I am trying to debug:
>
> [...]
>
> This code is coming from here http://www.dirac.org/linux/gdb/05-Stepping_And_Resuming.php#breakpointsandwatchpoints26. 
The original code with forward decl of display compiles without warning ;)
> It was supposed to stop at line 8 in main() but it stopped at line 9 it main(). For me it's misleading. I think it should stop at line 9, because this is what 'break' commands does - sets a break point at the very next instruction. But why "info breakpoints" said that the break point was set at line 8?
The behaviour is similar with setting a breakpoint at empty line 7 ("b
7") or function header line 13 ("b 13"): "i b" shows try5.c:7 resp.
try5.c:13, but the program stops at line 8 resp. 15.

The thing gets even fancier, when you rerun the program after setting
the breakpoints: Now "i b" lists your breakpoint at line 9, while my
breakpoints remain at line 7 resp. 13.

- Joachim


[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 5319 bytes --]

Re: Why does gdb stop at a different line than “i b” shows while returning from function?

[wempwer]

On Fri, Aug 03, 2012 at 11:15:42AM +0200, Joachim Protze wrote:
> The behaviour is similar with setting a breakpoint at empty line 7 ("b
> 7") or function header line 13 ("b 13"): "i b" shows try5.c:7 resp.
> try5.c:13, but the program stops at line 8 resp. 15.
> 

I would understand this because there are no instructions at line 7 and 13 so breakpoints have no effect on these lines and are automatically moved to the nearest next instruction. Is my understanding correct? 

However, my example is a bit different. I moved from 'display' to 'main' frame and set a breakpoint. I don't understand why gdb put the breakpoint on line 8 instead of 9, because this is the actual next instruction that's going to be executed in 'frame 1' and in fact when you resume the execution it stops at line 9 in 'main'. I think the breakpoint should be set at line 9 or if it must be set at line 8 it should not be triggered at line 9. There are no empty instructions such as '{' anywhere along the way in this situation.


> The thing gets even fancier, when you rerun the program after setting
> the breakpoints: Now "i b" lists your breakpoint at line 9, while my
> breakpoints remain at line 7 resp. 13.
> 
> - Joachim
> 

That's right, I didn't notice that before. Maybe it's a bug? I include the full log:

Reading symbols from /home/ja/gdb/learning/try5...done.
(gdb) b 7
Breakpoint 1 at 0x4004fb: file try5.c, line 7.
(gdb) b 13
Breakpoint 2 at 0x40051e: file try5.c, line 13.
(gdb) b display 
Note: breakpoint 2 also set at pc 0x40051e.
Breakpoint 3 at 0x40051e: file try5.c, line 15.
(gdb) r
Starting program: /home/ja/gdb/learning/try5 

Breakpoint 1, main () at try5.c:8
(gdb) c
Continuing.

Breakpoint 2, display (x=3) at try5.c:15
(gdb) f 1
#1  0x000000000040050c in main () at try5.c:8
(gdb) b
Breakpoint 4 at 0x40050c: file try5.c, line 8.
(gdb) c
Continuing.
i is 0.
i is 1.
i is 2.

Breakpoint 4, main () at try5.c:9
(gdb) c
Continuing.
[Inferior 1 (process 13038) exited normally]
(gdb) i b
Num     Type           Disp Enb Address            What
1       breakpoint     keep y   0x00000000004004fb in main at try5.c:7
	breakpoint already hit 1 time
2       breakpoint     keep y   0x000000000040051e in display at try5.c:13
	breakpoint already hit 1 time
3       breakpoint     keep y   0x000000000040051e in display at try5.c:15
	breakpoint already hit 1 time
4       breakpoint     keep y   0x000000000040050c in main at try5.c:8
	breakpoint already hit 1 time
(gdb) r
Starting program: /home/ja/gdb/learning/try5 

Breakpoint 1, main () at try5.c:8
(gdb) i b
Num     Type           Disp Enb Address            What
1       breakpoint     keep y   0x00000000004004fb in main at try5.c:7
	breakpoint already hit 1 time
2       breakpoint     keep y   0x000000000040051e in display at try5.c:13
3       breakpoint     keep y   0x000000000040051e in display at try5.c:15
4       breakpoint     keep y   0x000000000040050c in main at try5.c:9
(gdb)