This is the mail archive of the
binutils@sources.redhat.com
mailing list for the binutils project.
Re: MIPS multigot fixes for Linux
Daniel Jacobowitz <drow@mvista.com> writes:
> > *************** _bfd_mips_elf_finish_dynamic_symbol (out
> > *** 6692,6711 ****
> > offset = p->gotidx;
> > rel[0].r_offset = rel[1].r_offset = rel[2].r_offset = offset;
> >
> > ! MIPS_ELF_PUT_WORD (output_bfd, value, sgot->contents + offset);
> > !
> > ! if ((info->shared
> > ! || (elf_hash_table (info)->dynamic_sections_created
> > ! && p->d.h != NULL
> > ! && ((p->d.h->root.elf_link_hash_flags
> > ! & ELF_LINK_HASH_DEF_DYNAMIC) != 0)
> > ! && ((p->d.h->root.elf_link_hash_flags
> > ! & ELF_LINK_HASH_DEF_REGULAR) == 0)))
> > ! && ! (mips_elf_create_dynamic_relocation
> > ! (output_bfd, info, rel,
> > ! e.d.h, NULL, value, &addend, sgot)))
> > ! return FALSE;
> > ! BFD_ASSERT (addend == 0);
> > }
> > }
> > }
> > --- 6707,6729 ----
> > offset = p->gotidx;
> > rel[0].r_offset = rel[1].r_offset = rel[2].r_offset = offset;
> >
> > ! if (info->shared
> > ! || (elf_hash_table (info)->dynamic_sections_created
> > ! && p->d.h != NULL
> > ! && ((p->d.h->root.elf_link_hash_flags
> > ! & ELF_LINK_HASH_DEF_DYNAMIC) != 0)
> > ! && ((p->d.h->root.elf_link_hash_flags
> > ! & ELF_LINK_HASH_DEF_REGULAR) == 0)))
> > ! {
> > ! entry = 0;
> > ! if (! (mips_elf_create_dynamic_relocation
> > ! (output_bfd, info, rel,
> > ! e.d.h, NULL, sym->st_value, &entry, sgot)))
> > ! return FALSE;
> > ! }
> > ! else
> > ! entry = sym->st_value;
> > ! MIPS_ELF_PUT_WORD (output_bfd, entry, sgot->contents + offset);
> > }
> > }
> > }
> >
>
> The BFD_ASSERT used to not trigger. Therefore, you'll fill the GOT
> entry with 0 if you create a relocation and st_value if you don't.
> That will break Irix, I assume.
Hmm.... I'm not sure what you mean here. The BFD_ASSERT didn't used to
trigger when? Before your patch or after it? On irix or glibc? Like
I say, I think this patch is fixing a bug for irix too, so what happened
before on irix isn't necessarily a good benchmark.
The point is that the in-place addend _should_ contain the symbol value
in the irix case. Irix subtracts the old symbol value first, right?
I.e. the BFD_ASSERT should be removed even if we go with your patch.
I forgot about this in the review, sorry. ;(
I think the code above expresses exactly what we're trying to do.
If the entry can change, we create a standard R_MIPS_REL32 relocation
for it. If it can't change, we just store the final symbol value.
It's just like any other bit of data in most respects.
Richard