Re: mips gas is horribly broken

[Ian Lance Taylor <ian at zembu dot com>]

"H . J . Lu" <hjl@lucon.org> writes:

> On Wed, Jun 06, 2001 at 11:21:23PM -0700, Ian Lance Taylor wrote:
> > 
> > bfd_install_relocation has all the information that it needs.  The
> > problem is that it does the wrong thing.
> > 
> > If you want to incrementally improve it, I recommend that you consider
> > the section ``BFD relocation future'' which I wrote in
> > bfd/doc/bfdint.texi.
> > 
> > This is not a place for quick hacks.  Quick hacks got us where we are
> > today.  This is place for a designed approach.  Write the design, put
> > it out for comments, then implement it.
> 
> 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.
> 
> 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.

I think it would be inappropriate to add a new field to a heavily used
structure like reloc_cache_entry for this purpose.  That would
increase memory usage for most of the BFD programs for little gain.

If you are looking for a hack, perhaps you could add 1 to the addend
and subtract 1 from the contents of the object file?

Ian