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]
Other format: [Raw text]

Re: GOT refcounting broke non-refcount targets


On Thu, Aug 22, 2002 at 08:31:03AM +0930, Alan Modra wrote:
> On Wed, Aug 21, 2002 at 06:11:08PM -0400, Daniel Jacobowitz wrote:
> > But if got.offset is being used instead of got.refcount, then 0 is a valid
> > offset.
> 
> Oops.  My fault.
> 
> > Sparc has the same problem and even worse: the only use of got.refcount in
> > elf32-sparc.c is:
> >             if (h->got.refcount > 0)
> >               h->got.refcount--;
> 
> Rip the code out.  elf32_sparc_gc_sweep_hook is bogus.  It should
> just return true.

Rip out the whole function, I think you mean?  That makes sense from a
casual reading, all it plays with are the two refcounts and SPARC
refcounts neither of them.

> > Any comments?
> 
> Hmm, perhaps pass "struct elf_backend_data *" to copy_indirect_symbol
> (it's always called as bed->elf_backend_copy_indirect_symbol, so
> that is no bother), then do

Aha, I missed can_refcount (Should elf32-vax be setting that?  It looks
like it ought to, since it tries real hard to do the refcount
handling...).

> 
> void
> _bfd_elf_link_hash_copy_indirect (dir, ind, bed)
>      struct elf_link_hash_entry *dir, *ind;
>      struct elf_backend_data *bed;
> {
>   bfd_signed_vma tmp;
>   bfd_signed_vma lowest_valid = bed->can_refcount;
> .
> .
>   tmp = dir->got.refcount;
>   if (tmp < lowest_valid)
>     {
>       dir->got.refcount = ind->got.refcount;
>       ind->got.refcount = tmp;
>     }
>   else
>     BFD_ASSERT (ind->got.refcount < lowest_valid);
> .
> .
> }
> 
> Of course, that means editing more files.  I'll do the grunt work if
> you a) think it's better, and b) don't want to edit files yourself.  :)
> 
> 
> > +  else
> > +    BFD_ASSERT (ind->got.refcount <= 0);
> 
> I think this test should be < 0

Yes, you're right.

I like your suggestion.  One less bit of magic.  Mind doing the
gruntwork (since you offered :)?

Oh, Alan, if you see a way to write a testcase for this... I don't
understand the conditions well enough.  I think that anything that
causes the first GOT entry to go through the both copy_indirect paths in
elf_add_default_symbol will do it.  Readelf shows a corrupted
relocation table after.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer


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