Re: binutils problem

["H. J. Lu" <hjl at lucon dot org>]

On Mon, Aug 26, 2002 at 08:31:03AM +0930, Alan Modra wrote:
> On Sun, Aug 25, 2002 at 09:43:08PM +0200, Richard Zidlicky wrote:
> > On Sun, Aug 25, 2002 at 11:27:38AM -0400, Daniel Jacobowitz wrote:
> > > FWIW, this is the same symptom as the set of problems caused by not refcounting
> > > GOT/PLT entries.  m68k does refcount, but if there's a bug, there might
> > > be an uninitialized relocation.  Zeroing the section contents before
> > > filling them in will serve as a workaround (though not a fix).
> > 
> > zeroing which section when? Or how else could I narrow the problem
> > down?
> 
> Zeroing the reloc section is already done for m68k.  If m68k glibc
> rejects R_NONE relocs, then this problem will persist until
> bfd/elf32-m68k.c is rewritten to delay allocation of reloc slots as
> is currently done for x86, hppa, ppc64, s390 and just recently, sh,
> all using more or less the same scheme, and ia64, alpha and perhaps
> others.  A quick binutils fix is IMO not possible, but the rewrite
> should be fairly mechanical given the existing examples.

I don't think alpha is ok. The problem is -r and merged sections. As
the result,

# ld -r -o foo.os foo.o bar.o
# gcc -shared -o libfoo.so foo.os

may turn some relocations into R_NONE, comparing with

# gcc -shared -o libfoo.so foo.o bar.o



H.J.