Is that a GDB bug?

Is that a GDB bug?

[Nancy]

Hi,

Why line 5 execute twice?   Is that a GDB bug?

debug.c :
     1    int main()
     2    {
     3        int x;
     4        x=0;
     5        L1: switch(x) { case 0: x=1; goto L1;  case 1: if(x==0)
goto L1; else break; }
     6        x=2;
     7    }

$ gcc -O0 -g debug.c -o debug
$ gdb debug
GNU gdb (Ubuntu 7.7.1-0ubuntu5~14.04.2) 7.7.1
Copyright (C) 2014 Free Software Foundation, Inc.
....................
Reading symbols from debug...done.
(gdb) b 5
Breakpoint 1 at 0x80483fa: file debug.c, line 5.
(gdb) r
Starting program: /mnt/hgfs/cygwin/tmp/debug

Breakpoint 1, main () at debug.c:5
5        L1: switch(x) { case 0: x=1; goto L1;  case 1: if(x==0) goto
L1; else break; }
(gdb) n

Breakpoint 1, main () at debug.c:5
5        L1: switch(x) { case 0: x=1; goto L1;  case 1: if(x==0) goto
L1; else break; }
(gdb) n
6        x=2;


-- 
Best Regards,
Yu Rong Tan

Re: Is that a GDB bug?

[Mike Frysinger]

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

On 12 Oct 2015 20:46, Nancy wrote:
> Why line 5 execute twice?   Is that a GDB bug?

next operates on statements, not lines.  unwrap your code to be
readable (multiline) and it'll be more obvious.
-mike

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: Is that a GDB bug?

[Andreas Schwab]

Mike Frysinger <vapier@gentoo.org> writes:

> next operates on statements, not lines.

That's not true.

(gdb) help step
Step program until it reaches a different source line.

Andreas.

-- 
Andreas Schwab, SUSE Labs, schwab@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

Re: Is that a GDB bug?

[Mike Frysinger]

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

On 12 Oct 2015 15:32, Andreas Schwab wrote:
> Mike Frysinger <vapier@gentoo.org> writes:
> > next operates on statements, not lines.
> 
> That's not true.
> 
> (gdb) help step
> Step program until it reaches a different source line.

"next" != "step"
-mike

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: Is that a GDB bug?

[Simon Marchi]

On 12 October 2015 at 12:39, Mike Frysinger <vapier@gentoo.org> wrote:
> On 12 Oct 2015 15:32, Andreas Schwab wrote:
>> Mike Frysinger <vapier@gentoo.org> writes:
>> > next operates on statements, not lines.
>>
>> That's not true.
>>
>> (gdb) help step
>> Step program until it reaches a different source line.
>
> "next" != "step"

Andreas probably pasted the help for "step" because the help for
"next" refers to "step":

(gdb) help next
Step program, proceeding through subroutine calls.
Usage: next [N]
Unlike "step", if the current source line calls a subroutine,
this command does not enter the subroutine, but instead steps over
the call, in effect treating it as a single source line.

If I understand correctly (and please correct me if I'm wrong), the
debug info only maps each instruction to a line of the original source
file.  The algorithm for step/next when no subroutines are involved is
equivalent to "step instructions as long as they belong to the same
source line".  When the CPU is about to execute an instruction that
belongs to an other source line, we stop. So there is no knowledge of
statements.

You can verify what Pedro said by removing the breakpoint before doing the next:

(gdb) b 5
Breakpoint 1 at 0x80483d8: file test.c, line 5.
(gdb) r
Starting program: /tmp/binutils-gdb/gdb/test

Breakpoint 1, main () at test.c:5
5        L1: switch(x) { case 0: x=1; goto L1;  case 1: if(x==0) goto
L1; else break; }
(gdb) delete 1
(gdb) n
6        x=2;
(gdb)

Here, the next is not interrupted by the breakpoint, so the program
stops just before executing the first instruction that belongs to
x=2;.

Simon

Re: Is that a GDB bug?

[Andreas Schwab]

Mike Frysinger <vapier@gentoo.org> writes:

> On 12 Oct 2015 15:32, Andreas Schwab wrote:
>> Mike Frysinger <vapier@gentoo.org> writes:
>> > next operates on statements, not lines.
>> 
>> That's not true.
>> 
>> (gdb) help step
>> Step program until it reaches a different source line.
>
> "next" != "step"

next == step - subroutines

Andreas.

-- 
Andreas Schwab, SUSE Labs, schwab@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

Re: Is that a GDB bug?

[Pedro Alves]

On 10/12/2015 01:46 PM, Nancy wrote:
> Hi,
> 
> Why line 5 execute twice?   Is that a GDB bug?
> 
> debug.c :
>      1    int main()
>      2    {
>      3        int x;
>      4        x=0;
>      5        L1: switch(x) { case 0: x=1; goto L1;  case 1: if(x==0)
> goto L1; else break; }
>      6        x=2;
>      7    }
> 
> $ gcc -O0 -g debug.c -o debug
> $ gdb debug
> GNU gdb (Ubuntu 7.7.1-0ubuntu5~14.04.2) 7.7.1
> Copyright (C) 2014 Free Software Foundation, Inc.
> ....................
> Reading symbols from debug...done.
> (gdb) b 5
> Breakpoint 1 at 0x80483fa: file debug.c, line 5.
> (gdb) r
> Starting program: /mnt/hgfs/cygwin/tmp/debug
> 
> Breakpoint 1, main () at debug.c:5
> 5        L1: switch(x) { case 0: x=1; goto L1;  case 1: if(x==0) goto
> L1; else break; }
> (gdb) n

x starts as 0.  So the fist time, "goto L1" is executed.  That makes execution
flow back to the address where the breakpoint was inserted, so you get another
breakpoint hit:

> 
> Breakpoint 1, main () at debug.c:5
> 5        L1: switch(x) { case 0: x=1; goto L1;  case 1: if(x==0) goto
> L1; else break; }

It doesn't matter that "next" was in progress.  The breakpoint hit takes
priority.

> (gdb) n
> 6        x=2;
> 
> 

Thanks,
Pedro Alves