Re: mips gas is horribly broken

["H . J . Lu" <hjl at lucon dot org>]

On Thu, Jun 07, 2001 at 10:17:03PM -0700, Geoff Keating wrote:
> > Date: Thu, 7 Jun 2001 21:37:11 -0700
> > From: "H . J . Lu" <hjl@lucon.org>
> 
> > I am afraid I don't have the time to do what you suggested all by
> > myself. What I am looking for are
> > 
> > 1. Fix ELF/mips.
> > 2. No changes to other targets.
> > 3. Minimum changes to ELF/mips.
> 
> Oddly enough, these were the requirements of the _last_ person to
> "fix" this problem for mips.  They "fixed" the problem... for that one
> special case, by simply moving the point at which the addend becomes
> zero.
> 
> The problem is not just a problem for mips.  All ELF targets can hit
> it.  It's just that you've noticed it on mips.

I am willing to spend my time to fix any Linux/ELF targets if there is
a testcase. I have checked in a testcase for mips. If you have
testcases for other Linux/ELF targets, please check them in.

> 
> > I checked in a gas testcase for the problem I have. I noticed that
> > bfd_elf_generic_reloc called from bfd_install_relocation does the wrong
> > thing on ELF/mips. Basically, it should return bfd_reloc_continue. But
> > since reloc_entry->addend is 0 for that special case, bfd_reloc_ok is
> > returned instead. If somehow the assembler can pass that information
> > to a special bfd_elf_generic_reloc for mips, ELF/mips should be ok. I
> > am thinking to add a new field, adden_info, to reloc_cache_entry. The
> > ELF/mips assembler can set it if necessary. Then the mips special
> > bfd_elf_generic_reloc can check it in addition to reloc_entry->addend
> > when dicide what to return. The impact should be limited and I can
> > do it myself.
> 
> Yes, but it's not the right solution.  It would be an OK solution for
> your private tree, but not for everyone else.

All I ask is a working assembler for Linux/ELF targets. I can care
less how it is done and where it comes from.


H.J.