This is the mail archive of the
libc-alpha@sources.redhat.com
mailing list for the glibc project.
Re: [PATCH] Fix PLT infinite loop for cris-*-*.
- From: Hans-Peter Nilsson <hans-peter dot nilsson at axis dot com>
- To: roland at redhat dot com
- Cc: hans-peter dot nilsson at axis dot com, libc-alpha at sources dot redhat dot com, Uwe_Reimann at gmx dot net
- Date: Thu, 18 Sep 2003 00:03:11 +0200
- Subject: Re: [PATCH] Fix PLT infinite loop for cris-*-*.
> Date: Wed, 17 Sep 2003 14:31:10 -0700
> From: Roland McGrath <roland@redhat.com>
> > 2003-09-17 Uwe Reimann <Uwe_Reimann@gmx.net>
> > Hans-Peter Nilsson <hp@axis.com>
> >
> > * sysdeps/cris/dl-machine.h (elf_machine_type_class): Classify
> > R_CRIS_GLOB_DAT as ELF_RTYPE_CLASS_PLT. Clarify comment.
>
> I don't know the CRIS ELF spec to say whether the ld behavior is truly valid.
I don't know either, I haven't written the psABI yet. :-)
But a future such spec will, unless I hear from e.g. a glibc
person a reason against it.
> But if that's what GNU ld does now, glibc should work with such results.
> I put your change in.
Thanks.
The question is still open whether the runtime linker should
resolve symbols to be PLT entry addresses for any architecture,
in any case where the reloc using the symbol is that of a
user-visible reference (usually relocs called *_GLOB_DAT).
Should it? If so, that seems to mean that function pointers
will resolve to different values in different objects, breaking
pointer equality.
brgds, H-P