Re: bfd 2.10.90: Handle R_MIPS_REL32 relocations correctly

["Maciej W. Rozycki" <macro at ds2 dot pg dot gda dot pl>]

On Tue, 20 Jun 2000, Alan Modra wrote:

> >	* elf32-mips.c (_bfd_mips_elf_copy_indirect_symbol): New function.
> >	(elf_backend_copy_indirect_symbol): Map to the new function.
> >	Fix typos in comments.
> 
> What you're trying to achieve looks good to me, but why can't you just
> copy possibly_dynamic_relocs and min_dyn_reloc_index across?  Is it really
> necessary to merge these fields?  I know the generic code does this sort

 It won't work.  These fields have their semantics which I am preserving
here and if you have two relocations against the same symbol that come
from separate files, then the last one will override previous ones if a
plain copy is performed. 

> of thing, but from my cursory inspection of elf32-mips.c, it seems like
> the mips back-end will only update these values for the direct symbol.

 No, it updates them per relocation.  That's much before the symbol is
found and resolved in a shared object.

 I tried copying first, and it didn't work.  A hardware watchpoint
revealed that for a simple test case (void (*myfree)(void *) = free; see
also my other mail) is initially 0, then set to 1 (because of myfree's
relocation) and then to 0 again due to some crt clean-up code.  Summing
these up achieves the desired effect.

 I haven't tested min_dyn_reloc_index, actually, but given what I observed
I decided to keep it consistent as well. 

> Hmm, is it necessary to copy the fn_stub, need_fn_stub, call_stub and
> call_fp_stub fields too?

 No idea how to perform this -- it looks like they are of interest of
embedded people (they are related to MIPS16), so let them speak for
themselves.  I'm not sure whether they use weak symbols, though...

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +