From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31647 invoked by alias); 27 Mar 2014 15:40:40 -0000 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 Received: (qmail 31635 invoked by uid 89); 27 Mar 2014 15:40:39 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 27 Mar 2014 15:40:38 +0000 Received: from int-mx12.intmail.prod.int.phx2.redhat.com (int-mx12.intmail.prod.int.phx2.redhat.com [10.5.11.25]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s2RFeZgM011761 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 27 Mar 2014 11:40:35 -0400 Received: from redacted.bos.redhat.com ([10.18.17.143]) by int-mx12.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s2RFeXgR020039 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 27 Mar 2014 11:40:35 -0400 Date: Thu, 27 Mar 2014 15:40:00 -0000 From: Kyle McMartin To: Marcus Shawcroft Cc: "gdb-patches@sourceware.org" Subject: Re: [PATCHv2] aarch64: detect atomic sequences like other ll/sc architectures Message-ID: <20140327154033.GI3075@redacted.bos.redhat.com> References: <20140327015125.GE3075@redacted.bos.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-IsSubscribed: yes X-SW-Source: 2014-03/txt/msg00632.txt.bz2 On Thu, Mar 27, 2014 at 02:07:35PM +0000, Marcus Shawcroft wrote: > Are you sure these masks and patterns are accurate? Looks to me that > this excludes many of the load exclusive instructions and includes > part of the unallocated encoding space. There are several different > encodings to match here covering ld[a]xr{b,h,} and ld[a]xp. The masks > and patterns will be something like: > > 0xbfff7c00 0x085f7c00 > 0xbfff7c00 0x885f7c00 > 0xbfff0000 0x887f0000 > > > + if (decode_masked_match (insn, 0x3fc00000, 0x08000000)) > > This also looks wrong. > Eh... I tested all 24 possible ldxr/stxr opcodes... https://github.com/jkkm/aarch64-ldxr-stxr-match/blob/master/example.txt Maybe I'm missing something, but I think it's alright. > > + /* Test that we can step over ldxr/stxr. This sequence should step from > > + ldxr to the following __asm __volatile. */ > > + __asm __volatile ("1: ldxr %0,%2\n" \ > > + " cmp %0,#1\n" \ > > + " b.eq out\n" \ > > + " add %0,%0,1\n" \ > > + " stxr %w1,%0,%2\n" \ > > + " cbnz %w1,1b" \ > > + : "=&r" (tmp), "=&r" (cond), "+Q" (dword) \ > > + : : "memory"); > > + > > + /* This sequence should take the conditional branch and step from ldxr > > + to the return dword line. */ > > + __asm __volatile ("1: ldxr %0,%2\n" \ > > + " cmp %0,#1\n" \ > > + " b.eq out\n" \ > > + " add %0,%0,1\n" \ > > + " stxr %w1,%0,%2\n" \ > > + " cbnz %w1,1b\n" \ > > + : "=&r" (tmp), "=&r" (cond), "+Q" (dword) \ > > + : : "memory"); > > + > > + dword = -1; > > +__asm __volatile ("out:\n"); > > + return dword; > > +} > > How about testing at least one instruction from each group of load > store exclusives? > I'm just following what PPC64 did... I think the only thing they really want to check is that it correctly steps over the sequence (the original case didn't bother testing the conditional branch path.) I could add further cases, but it seems a bit pointless... but if you're going to block committing on that basis I guess I can cook it up. regards, Kyle > Cheers > /Marcus