From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14726 invoked by alias); 24 Jul 2013 17:25:11 -0000 Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org Received: (qmail 14712 invoked by uid 89); 24 Jul 2013 17:25:10 -0000 X-Spam-SWARE-Status: No, score=-1.5 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,RCVD_IN_DNSWL_MED,RDNS_NONE,TW_BJ,TW_CX,TW_DC,TW_GC,TW_GT,TW_GX autolearn=ham version=3.3.1 Received: from Unknown (HELO smtp.uoregon.edu) (128.223.142.146) by sourceware.org (qpsmtpd/0.84/v0.84-167-ge50287c) with ESMTP; Wed, 24 Jul 2013 17:25:09 +0000 Received: from cortana.d.cs.uoregon.edu (dyna6-184.cs.uoregon.edu [128.223.6.184]) (authenticated bits=0) by smtp.uoregon.edu (8.14.7/8.14.5) with ESMTP id r6OHOqxA022298 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 24 Jul 2013 10:24:59 -0700 From: Ender Dai To: "Abid\, Hafiz" Cc: "gdb\@sourceware.org" Subject: Re: gdb behavior on tight loop References: <87r4eopqdb.fsf@cortana.d.cs.uoregon.edu> Date: Wed, 24 Jul 2013 17:25:00 -0000 In-Reply-To: (Hafiz Abid's message of "Wed, 24 Jul 2013 12:23:40 +0000") Message-ID: <87mwpbq3a8.fsf@cortana.d.cs.uoregon.edu> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Proofpoint-Spam-Reason: safe X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.10.8794,1.0.431,0.0.0000 definitions=2013-07-24_07:2013-07-24,2013-07-24,1970-01-01 signatures=0 X-SW-Source: 2013-07/txt/msg00089.txt.bz2 "Abid, Hafiz" 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 > 0x00000000004004c1 <+13>: addl $0x1,-0x4(%rbp) > 0x00000000004004c5 <+17>: cmpl $0x1869f,-0x4(%rbp) > 0x00000000004004cc <+24>: jle 0x4004c1 > 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 >> >> 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: >> ... >> 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)