This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: [Bug gas/m68k] parse error with m68k-aout targets
- From: Gunther Nikl <gni at gecko dot de>
- To: Alan Modra <amodra at bigpond dot net dot au>
- Cc: binutils at sources dot redhat dot com
- Date: Mon, 28 Nov 2005 17:35:01 +0100
- Subject: Re: [Bug gas/m68k] parse error with m68k-aout targets
- References: <20051124111822.GA26386@lorien.int.gecko.de> <20051128123522.GA29043@bubble.grove.modra.org>
On Mon, Nov 28, 2005 at 11:05:22PM +1030, Alan Modra wrote:
> On Thu, Nov 24, 2005 at 12:18:22PM +0100, Gunther Nikl wrote:
> > gas214-bug.s: Assembler messages:
> > gas214-bug.s:4: Error: parse error -- statement `orl (mask.0),d0' ignored
> > gas214-bug.s:5: Error: parse error -- statement `orl d2,(mask.0)' ignored
> >
> > The testcase works fine with gas 2.9.1 and for m68k-elf. Note that for ELF
> > a register prefix has to be added.
>
> The trouble is that gas is seeing "(mask" and interpreting this as the
> start of "(<reg>)".
Thank you for this explanation. I was a puzzled by the messages since I
didn't know that GAS knows about a register called "mask". Even after
looking at the source I have no idea what "mask" should be.
> "mask" was added as a reg on 1999-05-28, so this has been around for a
> long time.
It is a hard to detect bug. It was now detected with binutils-2.14
sources because bfd/libbfd.c/warn_deprecated has a static variable
"mask". Since the variable is static it is emitted without a prepended
underscore with a.out systems. Thus by renaming the variable the
problem goes away for this particular source.
FYI, the last usable binutils version for my target (m68k-amigaos) was
2.9.1 since required modifications did only exist for that particular
version. Thus it wasn't possible to run into that bug before.
> The following patch would fix this particular problem, but I'm
> not applying it because it will break valid instructions like
> "tstl (%d0.w*2)".
Thats unfortunate :-(
> My 68k assembler is so rusty that I can't really help more than just
> pointing someone else at the right area. Sorry. I suspect that the
> right fix would be to move quite a bit of code from m68k-parse.y yylex
> to new parser rules to properly parse registers.
Maybe Ian Lance Taylor could help. I think he still knows m68k well
enough.
Thanks again for the insight and the patch.
Gunther