This is the mail archive of the
mailing list for the binutils project.
Re: PATCH: Handle R_ALPHA_NONE
On Tue, Apr 16, 2002 at 06:40:57PM -0700, H . J . Lu wrote:
> On Tue, Apr 16, 2002 at 05:31:40PM -0700, H . J . Lu wrote:
> > On Mon, Apr 15, 2002 at 11:48:35PM -0700, Richard Henderson wrote:
> > > On Mon, Apr 15, 2002 at 09:45:53PM -0700, H . J . Lu wrote:
> > > > The issue is ELF/alpha allocates more relocation entries for ld.so than
> > > > needed.
> > >
> > > But why? It is already trying to compute exactly how many
> > > are needed.
> > >
> > I am enclosing a testcase here. You need an alpha gcc which supports
> > string merge to duplcate it. I included .o files in my tarball so that
> > you can duplcate with a cross binutils.
> > # make
> > gcc -fPIC -O -c x.c
> > gcc -fPIC -O -c y.c
> > ld -r -m elf64alpha x.o y.o
> > ld -m elf64alpha -O1 -shared -o bad.so a.out -z nocombreloc
> > rm -f a.out
> > readelf -r bad.so | grep NONE
> > 000000000000 000000000000 R_ALPHA_NONE
> > 0000000000000000
> > ld -m elf64alpha -O1 -shared -o good.so x.o y.o -z nocombreloc
> > readelf -r good.so | grep NONE
> > make: *** [all] Error 1
> I think this patch
> generated R_ALPHA_NONE. Jakub, can you take a look at it?
The problem seems to be
addend = rel->r_addend;
while (gotent->gotobj != gotobj || gotent->addend != addend)
gotent = gotent->next;
_bfd_elf_rela_local_sym may change rel->r_addend. As the result, you
may not find the right gotent.