H. J. Lu
Sun Aug 25 19:48:00 GMT 2002
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
# 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
More information about the Binutils