From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24544 invoked by alias); 12 Jun 2012 13:06:12 -0000 Received: (qmail 24535 invoked by uid 22791); 12 Jun 2012 13:06:11 -0000 X-SWARE-Spam-Status: No, hits=-4.2 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,KHOP_THREADED,RCVD_IN_HOSTKARMA_W,RCVD_IN_HOSTKARMA_WL X-Spam-Check-By: sourceware.org Received: from relay1.mentorg.com (HELO relay1.mentorg.com) (192.94.38.131) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 12 Jun 2012 13:05:59 +0000 Received: from svr-orw-fem-01.mgc.mentorg.com ([147.34.98.93]) by relay1.mentorg.com with esmtp id 1SeQnF-0005Ju-84 from Luis_Gustavo@mentor.com ; Tue, 12 Jun 2012 06:05:57 -0700 Received: from NA1-MAIL.mgc.mentorg.com ([147.34.98.181]) by svr-orw-fem-01.mgc.mentorg.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 12 Jun 2012 06:05:56 -0700 Received: from [0.0.0.0] ([172.16.63.104]) by NA1-MAIL.mgc.mentorg.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 12 Jun 2012 06:05:56 -0700 Message-ID: <4FD73EB2.3070705@mentor.com> Date: Tue, 12 Jun 2012 13:06:00 -0000 From: Luis Gustavo Reply-To: "Gustavo, Luis" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.28) Gecko/20120313 Lightning/1.0b2 Thunderbird/3.1.20 MIME-Version: 1.0 To: Anton Blanchard CC: Joel Brobecker , gdb-patches@sourceware.org, emachado@linux.vnet.ibm.com Subject: Re: [PATCH 1/3] Fix ppc64 single step over atomic sequence testcase References: <20120606135557.7da37cbe@kryten> <20120611193326.GN2687@adacore.com> <20120612224515.15bc044d@kryten> In-Reply-To: <20120612224515.15bc044d@kryten> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2012-06/txt/msg00338.txt.bz2 Hi Anton, On 06/12/2012 09:45 AM, Anton Blanchard wrote: >> It would be useful for you to say what exactly is broken, and on >> which platform. At least it seems to have been working for some >> people (at IBM). > > Sorry the explanation was a bit terse. The testcase assumes it only > requires two "next"s to get through the test function: > > set bp1 [gdb_get_line_number "lwarx"] > gdb_breakpoint "$bp1" "Breakpoint $decimal at $hex" \ > "Set the breakpoint at the start of the sequence" > > gdb_test continue "Continuing.*Breakpoint $decimal.*" \ > "Continue until breakpoint" > > gdb_test next ".*__asm __volatile.*" \ > "Step through the lwarx/stwcx sequence" > > gdb_test next ".*return 0.*" \ > "Step through the ldarx/stdcx sequence" > > If I run this testcase manually on Fedora 16 (gcc 4.6.2), it > actually takes 7 steps to get through it: > > Breakpoint 2, main () at ./gdb.arch/ppc64-atomic-inst.c:27 > 27 __asm __volatile ("1: lwarx %0,0,%2\n" \ > (gdb) next > 32 : "b" (word_addr), "m" (*word_addr) \ > (gdb) next > 27 __asm __volatile ("1: lwarx %0,0,%2\n" \ > (gdb) next > 39 : "=&b" (dword), "=m" (*dword_addr) \ > (gdb) next > 35 __asm __volatile ("1: ldarx %0,0,%2\n" \ > (gdb) next > 40 : "b" (dword_addr), "m" (*dword_addr) \ > (gdb) next > 35 __asm __volatile ("1: ldarx %0,0,%2\n" \ > (gdb) next > 43 return 0; > (gdb) > > I'm not sure what is expected here, is "next" supposed to step all the > way through inline assembly? Perhaps it is, but it seems fragile to > depend on this high level behaviour. I authored that testcase a while ago. For the most common case we didn't have multiple branch instructions inside such a sequence IIRC, but if we have that now, the testcase should definitely be updated. GDB is supposed to skip eacho sequence (__asm__ block) in response to a "next", but it may have had its behavior changed from when i originally wrote this. It seems to take multiple next's to get to a different __asm__ block now, so it seems to be broken. It may be a difference in GCC's debuginfo output or GDB just got smarter. Regards, Luis