From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8332 invoked by alias); 3 May 2012 07:39:07 -0000 Received: (qmail 8233 invoked by uid 22791); 3 May 2012 07:39:04 -0000 X-SWARE-Spam-Status: No, hits=-2.7 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,KHOP_RCVD_TRUST,KHOP_THREADED,RCVD_IN_DNSWL_LOW,RCVD_IN_HOSTKARMA_YE X-Spam-Check-By: sourceware.org Received: from mail-yx0-f169.google.com (HELO mail-yx0-f169.google.com) (209.85.213.169) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 03 May 2012 07:38:48 +0000 Received: by yenm8 with SMTP id m8so1820511yen.0 for ; Thu, 03 May 2012 00:38:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.50.194.163 with SMTP id hx3mr80810igc.49.1336030727368; Thu, 03 May 2012 00:38:47 -0700 (PDT) Received: by 10.42.222.194 with HTTP; Thu, 3 May 2012 00:38:47 -0700 (PDT) In-Reply-To: References: Date: Thu, 03 May 2012 07:39:00 -0000 Message-ID: Subject: Unstable GDB results due to change in dl_debug_state() From: jiji vinitha To: gdb@sourceware.org Cc: vijuvince@gmail.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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 X-SW-Source: 2012-05/txt/msg00007.txt.bz2 Hi All, =A0 I have been testing gdb-7.2 in an smp kernel in ARM cortex-A9 environme= nt. =A0 I am getting more than 1000 additional failures. It appears that this happens only in case of SMP kernel. On uP kernel any additional unexpected failures are not reported. The testsuite behaviour appears to be unstable in SMP kernel environment. For eg, the testcase ending-run.exp it shows unstable behaviour as shown be= low. =A0* The testcases passes sometimes as shown below {{{ Running ./gdb.base/ending-run.exp ... =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =3D=3D=3D gdb Summary =3D=3D= =3D # of expected passes=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 19 # of unsupported tests=A0=A0=A0=A0=A0=A0=A0=A0=A0 1 }}} =A0* Sometimes it fails as shown below {{{ Running ./gdb.base/ending-run.exp ... FAIL: gdb.base/ending-run.exp: run (the program exited) FAIL: gdb.base/ending-run.exp: clear worked FAIL: gdb.base/ending-run.exp: cleared bp at line before routine FAIL: gdb.base/ending-run.exp: Cleared 2 by line FAIL: gdb.base/ending-run.exp: Clear 2 by default FAIL: gdb.base/ending-run.exp: all set to continue (didn't clear bps) FAIL: gdb.base/ending-run.exp: cont (the program is no longer running) FAIL: gdb.base/ending-run.exp: Step to return (the program is no longer run= ning) FAIL: gdb.base/ending-run.exp: step out of main (the program is no longer running) FAIL: gdb.base/ending-run.exp: step to end of run (the program is no longer running) =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =3D=3D=3D gdb Summary =3D=3D= =3D # of expected passes=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 8 # of unexpected failures=A0=A0=A0=A0=A0=A0=A0 10 # of unsupported tests=A0=A0=A0=A0=A0=A0=A0=A0=A0 2 }}} On analyzing gdb.log in the failed case it is observed that, the binary is not stopping at breakpoints. The 'run' command results in program running completely and exiting without stopping at breakpoints. {{{ ... b ending-run.c:1^M Breakpoint 1 at 0x84d0: file ./gdb.base/ending-run.c, line 1.^M (gdb) PASS: gdb.base/ending-run.exp: bpt at line before routine b ending-run.c:14^M Note: breakpoint 1 also set at pc 0x84d0.^M Breakpoint 2 at 0x84d0: file ./gdb.base/ending-run.c, line 14.^M (gdb) PASS: gdb.base/ending-run.exp: b ending-run.c:14, one b ending-run.c:31^M Breakpoint 3 at 0x853c: file ./gdb.base/ending-run.c, line 31.^M (gdb) PASS: gdb.base/ending-run.exp: b ending-run.c:31 run ^M Starting program: /mnt/test/gdb-test-7.2/glibc/gdb-7.2.glibc/gdb/testsuite/gdb.base/ending-run ^M -1 2 7 14 23 34 47 62 79=A0 Goodbye!^M ^M Program exited normally.^M (gdb) FAIL: gdb.base/ending-run.exp: run (the program exited) cle^M No source file specified.^M (gdb) FAIL: gdb.base/ending-run.exp: clear worked i b^M Num=A0=A0=A0=A0 Type=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Disp Enb Address=A0=A0= =A0 What^M 1=A0=A0=A0=A0=A0=A0 breakpoint=A0=A0=A0=A0 keep y=A0=A0 0x000084d0 in calle= e at ./gdb.base/ending-run.c:1^M 2=A0=A0=A0=A0=A0=A0 breakpoint=A0=A0=A0=A0 keep y=A0=A0 0x000084d0 in calle= e at ./gdb.base/ending-run.c:14^M 3=A0=A0=A0=A0=A0=A0 breakpoint=A0=A0=A0=A0 keep y=A0=A0 0x0000853c in main = at ./gdb.base/ending-run.c:31^M (gdb) FAIL: gdb.base/ending-run.exp: cleared bp at line before routine ... }}} =A0* The glibc version I am using is glibc-2.11.2. =A0* And recently we have removed the frame pointer support from glibc. (not using -fno-omit-framepointer with -O2). =A0 * The disassembly of dl_debug_state function in ld.so is as shown below (not using -fno-omit-framepointer with -O2). {{{ 0000b6d8 <_dl_debug_state>: =A0=A0=A0 b6d8:=A0=A0=A0=A0=A0=A0 4770=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 bx= =A0=A0=A0=A0=A0 lr =A0=A0=A0 b6da:=A0=A0=A0=A0=A0=A0 bf00=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 nop }}} =A0* The glibc-2.11.2 built with -fno-omit-framepointer works fine in SMP and uP kernel enviroments. =A0 * The disassembly of dl_debug_state function in ld.so is as shown below (built with -fno-omit-framepointer) {{{ 0000aee8 <_dl_debug_state>: =A0=A0=A0 aee8:=A0=A0=A0=A0=A0=A0 b480=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 pus= h=A0=A0=A0 {r7} =A0=A0=A0 aeea:=A0=A0=A0=A0=A0=A0 af00=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 add= =A0=A0=A0=A0 r7, sp, #0 =A0=A0=A0 aeec:=A0=A0=A0=A0=A0=A0 46bd=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 mov= =A0=A0=A0=A0 sp, r7 =A0=A0=A0 aeee:=A0=A0=A0=A0=A0=A0 bc80=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 pop= =A0=A0=A0=A0 {r7} =A0=A0=A0 aef0:=A0=A0=A0=A0=A0=A0 4770=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 bx= =A0=A0=A0=A0=A0 lr =A0=A0=A0 aef2:=A0=A0=A0=A0=A0=A0 bf00=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 nop }}} =A0* We found that the change in _dl_debug_state() causing unstable behaviour in GDB testsuite. =A0* We have tested by adding some nop instructions in the _dl_debug_state() as shown below. {{{ 0000b6d8 <_dl_debug_state>: 0000b6d8:=A0=A0=A0=A0=A0=A0 bf00=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 nop 0000b6da:=A0=A0=A0=A0=A0=A0 bf00=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 nop 0000b6dc:=A0=A0=A0=A0=A0=A0 bf00=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 nop 0000b6de:=A0=A0=A0=A0=A0=A0 4770=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 bx=A0=A0= =A0=A0=A0 lr }}} =A0* In this case also the GDB test results are stable. =A0* As GDB is putting internal breakpoint on _dl_debug_state to monitor shared library events =A0=A0 and since the change in assembly of this function is causing an unstable behaviour in the gdb testsuite results, =A0=A0 we tried putting gdb internal breakpoint on another function in ld.so ( _dl_unload_cache()) =A0=A0 which is getting called from dl_main() after call to dl_debug_state(= ). {{{ --- gdb-7.2.orig/gdb/solib-svr4.c +++ gdb-7.2/gdb/solib-svr4.c @@ -84,6 +84,7 @@ static char *solib_break_names[] =3D =A0{ =A0=A0 "r_debug_state", =A0=A0 "_r_debug_state", +=A0 "_dl_unload_cache", =A0=A0 "_dl_debug_state", =A0=A0 "rtld_db_dlactivity", =A0=A0 "__dl_rtld_db_dlactivity", }}} =A0* In this case GDB test results are stable. =A0* It seems there is some issue when running gdb testsuite, in a SMP kernel environment when glibc is built without framepointer. NB: normal debugging is working fine. Only dejagnu testsuite shows unstable results. Has anyone got similar kind of issue related to gdb testsuite ? Regards, Vinitha Vijayan