From: Vidya Praveen <vidyapraveen@arm.com>
To: Nicholas Clifton <nickc@redhat.com>
Cc: Hans-Peter Nilsson <hans-peter.nilsson@axis.com>,
"gdb-patches@sourceware.org" <gdb-patches@sourceware.org>,
"binutils@sourceware.org" <binutils@sourceware.org>
Subject: Re: Fix sim fallout from arm assembler complaining about symbols named as insns
Date: Wed, 06 May 2015 13:49:00 -0000 [thread overview]
Message-ID: <20150506134921.GA1052@e103625-lin.cambridge.arm.com> (raw)
In-Reply-To: <5549EEDC.7040707@redhat.com>
On Wed, May 06, 2015 at 11:37:16AM +0100, Nicholas Clifton wrote:
> Hi Hans-Peter,
>
> > 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?
>
> No, but they can be a little bit confusing and the problem I was trying
> to solve, of an instruction name being mistakenly treated as a symbol,
> is genuine. It would be better I agree to restrict this check to just
> the case where the "=" assignment operator is being used, but I did not
> 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.
For example, simply having a global variable called "str" in a C program (which
is perfectly valid) can trigger this warning. In fact quite a few gcc tests
fail at the moment because of this.
VP.
> > To wit, right now, the new symbol "sanity-check" causes failures
> > for --target arm-eabi check-sim:
>
> So it does. I should have checked that before committing the patch. Sorry.
>
>
> > +2015-05-02 Hans-Peter Nilsson <hp@axis.com>
> > +
> > + * 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.
>
> I think that this is a good solution - please apply.
next prev parent reply other threads:[~2015-05-06 13:49 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-05-02 0:17 Hans-Peter Nilsson
2015-05-06 10:37 ` Nicholas Clifton
2015-05-06 13:49 ` Vidya Praveen [this message]
2015-05-07 6:36 ` Mike Frysinger
2015-05-07 23:57 ` Hans-Peter Nilsson
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20150506134921.GA1052@e103625-lin.cambridge.arm.com \
--to=vidyapraveen@arm.com \
--cc=binutils@sourceware.org \
--cc=gdb-patches@sourceware.org \
--cc=hans-peter.nilsson@axis.com \
--cc=nickc@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox