This is the mail archive of the binutils@sources.redhat.com mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: mips gas is horribly broken


> 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 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.

-- 
- Geoffrey Keating <geoffk@geoffk.org>


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]