Re: More problems with MIPS gas relocations

[cgd at broadcom dot com]

"H . J . Lu" <hjl@lucon.org> writes:
> Why should my changes clobber non-elf targets? I thought they were
> protected by
> 
> #ifdef OBJ_ELF
> ....
> #endif
> 
> Did I miss something?

Well, other code which is similarly protected either:

(a) look harmless on non-ELF, or

(b) is protected more completely, using a check like:

#ifdef OBJ_ELF 
  if (OUTPUT_FLAVOR == bfd_target_elf_flavour
      && S_GET_OTHER (fixp->fx_addsy) == STO_MIPS16 
      && fixp->fx_subsy == NULL)
    return 0;
#endif    

looking at obj-*.h, it looks like there's the possibility to have ELF
support compiled in along with other object format support, used
presumably based on emulation selected at run time.

looking at the configury, it appears that at minimum MIPS targets
matching mips-*-irix5*-*, and possibly others, will invoke that
support.


> > > If there is no DSO
> > > involved, those patches may not be needed. But other other hand, the
> > > linker should be able to do the right thing during the final link.
> > 
> > And it does, modulo the seemingly-incorrect value that's left in the
> > instruction.
> > 
> 
> Did Ricard's patch fix it?

Richard's patch didn't do anything related to the problem I was
seeing.  (It just touched the same area of code as my fix did, and so
caught my attention.)


> > > I
> > > don't use -membedded-pic and I have no idea what it does.
> > 
> > It's a way of generating PIC code for embedded use.
> > 
> > It's not currently fully supported on MIPS ELF, though it was
> > apparently supported at one time in ECOFF.  (Based on test results, it
> > seems broken there now, though.)
> 
> If the -membedded-pic is not compatible with the SVR4 MIPS ABI, I
> don't know how you can get it to work without creating a new BFD
> target for it.

So, looking at the existing tc-mips.c, it's supposed to be able to,
with a single binary, create code compatible with multiple PIC code
ABIs.

In particular, the variable "mips_pic" is used to select between
different the variants:

enum mips_pic_level
{
  /* Do not generate PIC code.  */
  NO_PIC,
  
  /* Generate PIC code as in Irix 4.  This is not implemented, and I'm
     not sure what it is supposed to do.  */
  IRIX4_PIC,
 
  /* Generate PIC code as in the SVR4 MIPS ABI.  */
  SVR4_PIC,

  /* Generate PIC code without using a global offset table: the data
     segment has a maximum size of 64K, all data references are off
     the $gp register, and all text references are PC relative.  This
     is used on some embedded systems.  */
  EMBEDDED_PIC
};

I don't believe that embedded-pic is fundamentally incompatible with
the changes you've made for SysV ABI support.  There's just at least
one bug in the reloc calculations caused by those changes.  (either
the old or new-with-bug-fix type of reloc works, it seems, and based
on the actual reloc values i'd expect that they'd even interoperate.)

However, I will note that the targets i've been configuring for
haven't changed: mips{,el}-elf (and the 64-bit variants).  so if
incompatible ABI changes _have_ snuck in to the generic mips-elf code,
I don't know that i'd call them "features."  8-)


cgd