gdb behavior on tight loop

gdb behavior on tight loop

[Ender Dai]

Hi,

I just find some counterintuitive (to me) behavior of gdb on tight
loop. Please see the gdb session below. When I run "next" on line 5, the
tight loop, it will take several seconds before gdb stop on line 6 and I
regain control. Strace shows that it looks like gdb is doing some magic
in every iteration.

If I set an additional breackpoint on line 6, and "continue" on line 5
instead of "next", everything looks good.

Is this supposed behavior? What is gdb doing undercover?

(There is a warning message about vdso, but google tell me that it
should be fine...)

Thanks,
Ender

$ gdb a.out 
GNU gdb (GDB) 7.6 (Debian 7.6-5)
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
<http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show
copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /home/ender/src/tmp/a.out...done.
(gdb) l
1     int
2     main(void)
3     {
4       int i;
5       for (i=0; i<100000; i++);
6       return 0;
7     }
(gdb) b 5
Breakpoint 1 at 0x4004b1: file loop.c, line 5.
(gdb) r
Starting program: /home/xdai/src/tmp/a.out 
warning: no loadable sections found in added symbol-file system-supplied
DSO at 0x7ffff7ffa000
warning: Could not load shared library symbols for linux-vdso.so.1.
Do you need "set solib-search-path" or "set sysroot"?

Breakpoint 1, main () at loop.c:5
5      for (i=0; i<100000; i++);
(gdb) n
6      return 0;
(gdb) 

$ uname -a
Linux cortana 3.9-1-amd64 #1 SMP Debian 3.9.8-1 x86_64 GNU/Linux

$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.8/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 4.8.1-7'
--with-bugurl=file:///usr/share/doc/gcc-4.8/README.Bugs
--enable-languages=c,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-4.8 --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--with-gxx-include-dir=/usr/include/c++/4.8 --libdir=/usr/lib
--enable-nls --with-sysroot=/ --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes
--enable-gnu-unique-object --enable-plugin --with-system-zlib
--disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo
--with-java-home=/usr/lib/jvm/java-1.5.0-gcj-4.8-amd64/jre
--enable-java-home
--with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-4.8-amd64
--with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-4.8-amd64
--with-arch-directory=amd64
--with-ecj-jar=/usr/share/java/eclipse-ecj.jar --enable-objc-gc
--enable-multiarch --with-arch-32=i586 --with-abi=m64
--with-multilib-list=m32,m64,mx32 --with-tune=generic
--enable-checking=release --build=x86_64-linux-gnu
--host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 4.8.1 (Debian 4.8.1-7) 

RE: gdb behavior on tight loop

[Abid, Hafiz]

> -----Original Message-----
> From: gdb-owner@sourceware.org [mailto:gdb-owner@sourceware.org] On
> Behalf Of Ender Dai
> Sent: 24 July 2013 04:51
> To: gdb@sourceware.org
> Subject: gdb behavior on tight loop
> 
> Hi,
> 
> I just find some counterintuitive (to me) behavior of gdb on tight loop.
> Please see the gdb session below. When I run "next" on line 5, the tight
> loop, it will take several seconds before gdb stop on line 6 and I regain
> control. Strace shows that it looks like gdb is doing some magic in every
> iteration.
> 
> If I set an additional breackpoint on line 6, and "continue" on line 5 instead
> of "next", everything looks good.
> 
> Is this supposed behavior? What is gdb doing undercover?
For 'next', GDB keeps doing low level step until It goes out of the range of current line.
When you issue next on line 5, GDB steps one instruction and checks the PC. It will keep doing steps until PC is out of the
Range of line 5 [0x4004b8-0x4004cd]. It is stopping after every instruction and then checking PC that is taking the time.

5	  for (i=0; i<100000; i++);
   0x00000000004004b8 <+4>:	movl   $0x0,-0x4(%rbp)
   0x00000000004004bf <+11>:	jmp    0x4004c5 <main+17>
   0x00000000004004c1 <+13>:	addl   $0x1,-0x4(%rbp)
   0x00000000004004c5 <+17>:	cmpl   $0x1869f,-0x4(%rbp)
   0x00000000004004cc <+24>:	jle    0x4004c1 <main+13>
6	    return 0;
   0x00000000004004ce <+26>:	mov    $0x0,%eax 

You can get more details of what GDB is doing undercover using "set debug infrun 1" command.

> (There is a warning message about vdso, but google tell me that it should be
> fine...)
> 
> Thanks,
> Ender
> 
> $ gdb a.out
> GNU gdb (GDB) 7.6 (Debian 7.6-5)
> Copyright (C) 2013 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later
> <http://gnu.org/licenses/gpl.html>
> This is free software: you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law.  Type "show
> copying"
> and "show warranty" for details.
> This GDB was configured as "x86_64-linux-gnu".
> For bug reporting instructions, please see:
> <http://www.gnu.org/software/gdb/bugs/>...
> Reading symbols from /home/ender/src/tmp/a.out...done.
> (gdb) l
> 1     int
> 2     main(void)
> 3     {
> 4       int i;
> 5       for (i=0; i<100000; i++);
> 6       return 0;
> 7     }
> (gdb) b 5
> Breakpoint 1 at 0x4004b1: file loop.c, line 5.
> (gdb) r
> Starting program: /home/xdai/src/tmp/a.out
> warning: no loadable sections found in added symbol-file system-supplied
> DSO at 0x7ffff7ffa000
> warning: Could not load shared library symbols for linux-vdso.so.1.
> Do you need "set solib-search-path" or "set sysroot"?
> 
> Breakpoint 1, main () at loop.c:5
> 5      for (i=0; i<100000; i++);
> (gdb) n
> 6      return 0;
> (gdb)
> 
> $ uname -a
> Linux cortana 3.9-1-amd64 #1 SMP Debian 3.9.8-1 x86_64 GNU/Linux
> 
> $ gcc -v
> Using built-in specs.
> COLLECT_GCC=gcc
> COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.8/lto-wrapper
> Target: x86_64-linux-gnu
> Configured with: ../src/configure -v --with-pkgversion='Debian 4.8.1-7'
> --with-bugurl=file:///usr/share/doc/gcc-4.8/README.Bugs
> --enable-languages=c,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr
> --program-suffix=-4.8 --enable-shared --enable-linker-build-id --
> libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
> --with-gxx-include-dir=/usr/include/c++/4.8 --libdir=/usr/lib --enable-nls --
> with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-
> libstdcxx-time=yes --enable-gnu-unique-object --enable-plugin --with-system-
> zlib --disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo --with-
> java-home=/usr/lib/jvm/java-1.5.0-gcj-4.8-amd64/jre
> --enable-java-home
> --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-4.8-amd64
> --with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-4.8-amd64
> --with-arch-directory=amd64
> --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --enable-objc-gc --enable-
> multiarch --with-arch-32=i586 --with-abi=m64
> --with-multilib-list=m32,m64,mx32 --with-tune=generic --enable-
> checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --
> target=x86_64-linux-gnu Thread model: posix gcc version 4.8.1 (Debian 4.8.1-
> 7)

Re: gdb behavior on tight loop

[Ender Dai]

"Abid, Hafiz" <Hafiz_Abid@mentor.com> writes:

>> 
>> I just find some counterintuitive (to me) behavior of gdb on tight loop.
>> Please see the gdb session below. When I run "next" on line 5, the tight
>> loop, it will take several seconds before gdb stop on line 6 and I regain
>> control. Strace shows that it looks like gdb is doing some magic in every
>> iteration.
>> 
>> If I set an additional breackpoint on line 6, and "continue" on line 5 instead
>> of "next", everything looks good.
>> 
>> Is this supposed behavior? What is gdb doing undercover?
> For 'next', GDB keeps doing low level step until It goes out of the range of current line.
> When you issue next on line 5, GDB steps one instruction and checks the PC. It will keep doing steps until PC is out of the
> Range of line 5 [0x4004b8-0x4004cd]. It is stopping after every instruction and then checking PC that is taking the time.
>

Thanks, this makes sense.

> 5	  for (i=0; i<100000; i++);
>    0x00000000004004b8 <+4>:	movl   $0x0,-0x4(%rbp)
>    0x00000000004004bf <+11>:	jmp    0x4004c5 <main+17>
>    0x00000000004004c1 <+13>:	addl   $0x1,-0x4(%rbp)
>    0x00000000004004c5 <+17>:	cmpl   $0x1869f,-0x4(%rbp)
>    0x00000000004004cc <+24>:	jle    0x4004c1 <main+13>
> 6	    return 0;
>    0x00000000004004ce <+26>:	mov    $0x0,%eax 
>
> You can get more details of what GDB is doing undercover using "set debug infrun 1" command.
>

Good to know that. It helps.

>> 
>> $ gdb a.out
>> GNU gdb (GDB) 7.6 (Debian 7.6-5)
>> Copyright (C) 2013 Free Software Foundation, Inc.
>> License GPLv3+: GNU GPL version 3 or later
>> <http://gnu.org/licenses/gpl.html>
>> This is free software: you are free to change and redistribute it.
>> There is NO WARRANTY, to the extent permitted by law.  Type "show
>> copying"
>> and "show warranty" for details.
>> This GDB was configured as "x86_64-linux-gnu".
>> For bug reporting instructions, please see:
>> <http://www.gnu.org/software/gdb/bugs/>...
>> Reading symbols from /home/ender/src/tmp/a.out...done.
>> (gdb) l
>> 1     int
>> 2     main(void)
>> 3     {
>> 4       int i;
>> 5       for (i=0; i<100000; i++);
>> 6       return 0;
>> 7     }
>> (gdb) b 5
>> Breakpoint 1 at 0x4004b1: file loop.c, line 5.
>> (gdb) r
>> Starting program: /home/xdai/src/tmp/a.out
>> warning: no loadable sections found in added symbol-file system-supplied
>> DSO at 0x7ffff7ffa000
>> warning: Could not load shared library symbols for linux-vdso.so.1.
>> Do you need "set solib-search-path" or "set sysroot"?
>> 
>> Breakpoint 1, main () at loop.c:5
>> 5      for (i=0; i<100000; i++);
>> (gdb) n
>> 6      return 0;
>> (gdb)
>> 
>> $ uname -a
>> Linux cortana 3.9-1-amd64 #1 SMP Debian 3.9.8-1 x86_64 GNU/Linux
>> 
>> $ gcc -v
>> Using built-in specs.
>> COLLECT_GCC=gcc
>> COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.8/lto-wrapper
>> Target: x86_64-linux-gnu
>> Configured with: ../src/configure -v --with-pkgversion='Debian 4.8.1-7'
>> --with-bugurl=file:///usr/share/doc/gcc-4.8/README.Bugs
>> --enable-languages=c,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr
>> --program-suffix=-4.8 --enable-shared --enable-linker-build-id --
>> libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
>> --with-gxx-include-dir=/usr/include/c++/4.8 --libdir=/usr/lib --enable-nls --
>> with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-
>> libstdcxx-time=yes --enable-gnu-unique-object --enable-plugin --with-system-
>> zlib --disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo --with-
>> java-home=/usr/lib/jvm/java-1.5.0-gcj-4.8-amd64/jre
>> --enable-java-home
>> --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-4.8-amd64
>> --with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-4.8-amd64
>> --with-arch-directory=amd64
>> --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --enable-objc-gc --enable-
>> multiarch --with-arch-32=i586 --with-abi=m64
>> --with-multilib-list=m32,m64,mx32 --with-tune=generic --enable-
>> checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --
>> target=x86_64-linux-gnu Thread model: posix gcc version 4.8.1 (Debian 4.8.1-
>> 7)

Re: gdb behavior on tight loop

[John Gilmore]

> >> Please see the gdb session below. When I run "next" on line 5, the tight
> >> loop, it will take several seconds before gdb stop on line 6 and I regain
> >> control. 
> >>
> >> If I set an additional breackpoint on line 6, and "continue" on line 5 instead
> >> of "next", everything looks good.

In situations like this, the "until" command is convenient.
You can say "u 6" and gdb will set a temporary breakpoint at line 6,
run the program at full speed until it hits that breakpoint (or some
other breakpoint or error) and then remove the temporary breakpoint.

	John Gilmore