From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 112632 invoked by alias); 6 May 2015 13:49:28 -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 112620 invoked by uid 89); 6 May 2015 13:49:28 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.3.2 X-HELO: eu-smtp-delivery-143.mimecast.com Received: from eu-smtp-delivery-143.mimecast.com (HELO eu-smtp-delivery-143.mimecast.com) (146.101.78.143) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 06 May 2015 13:49:27 +0000 Received: from cam-owa1.Emea.Arm.com (fw-tnat.cambridge.arm.com [217.140.96.140]) by uk-mta-25.uk.mimecast.lan; Wed, 06 May 2015 14:49:23 +0100 Received: from e103625-lin.cambridge.arm.com ([10.1.2.79]) by cam-owa1.Emea.Arm.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 6 May 2015 14:49:23 +0100 Date: Wed, 06 May 2015 13:49:00 -0000 From: Vidya Praveen To: Nicholas Clifton Cc: Hans-Peter Nilsson , "gdb-patches@sourceware.org" , "binutils@sourceware.org" Subject: Re: Fix sim fallout from arm assembler complaining about symbols named as insns Message-ID: <20150506134921.GA1052@e103625-lin.cambridge.arm.com> References: <201505020017.t420Hn09026225@ignucius.se.axis.com> <5549EEDC.7040707@redhat.com> MIME-Version: 1.0 In-Reply-To: <5549EEDC.7040707@redhat.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-MC-Unique: kwBet-C7RbqVkHwxjYfnkA-1 Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-IsSubscribed: yes X-SW-Source: 2015-05/txt/msg00099.txt.bz2 On Wed, May 06, 2015 at 11:37:16AM +0100, Nicholas Clifton wrote: > Hi Hans-Peter, >=20 > > I'm not completely sure this new gas warning is a good thing. > > I mean, symbols such as those below don't really interfere with > > the insn namespace, do they? >=20 > No, but they can be a little bit confusing and the problem I was trying=20 > to solve, of an instruction name being mistakenly treated as a symbol,=20 > is genuine. It would be better I agree to restrict this check to just=20 > the case where the "=3D" assignment operator is being used, but I did not= =20 > want to modify generic code. Maybe I should have done that. :-( Yes. I think the warning should just restrict to cases where it can possibly go wrong. There can be too many false positives with the current solution as it warns if a symbol name merely matches a mnemonic.=20 For example, simply having a global variable called "str" in a C program (w= hich is perfectly valid) can trigger this warning. In fact quite a few gcc tests= =20 fail at the moment because of this.=20 VP. > > To wit, right now, the new symbol "sanity-check" causes failures > > for --target arm-eabi check-sim: >=20 > So it does. I should have checked that before committing the patch. Sor= ry. >=20 >=20 > > +2015-05-02 Hans-Peter Nilsson > > + > > + * bl.cgs (bl0): Rename from symbol colliding with insn name bl. > > + * iwmmxt/tmia.cgs (tmia0): Similar. > > + * iwmmxt/tmiaph.cgs (tmiaph0): Similar. > > + * iwmmxt/waligni.cgs (waligni0): Similar. > > + * iwmmxt/wand.cgs (wand0): Similar. > > + * iwmmxt/wandn.cgs (wandn0): Similar. > > + * iwmmxt/wmov.cgs (wmov0): Similar. > > + * iwmmxt/wor.cgs (wor0): Similar. > > + * iwmmxt/wshufh.cgs (wshuf0): Similar. > > + * iwmmxt/wxor.cgs (wxor0): Similar. > > + * iwmmxt/wzero.cgs (wzero0): Similar. > > + * xscale/mia.cgs (mia0): Similar. > > + * xscale/miaph.cgs (miaph0): Similar. >=20 > I think that this is a good solution - please apply. =20