This is the mail archive of the
libc-alpha@sources.redhat.com
mailing list for the glibc project.
RFC: STO_COPY again: Re: Copy relocation and protected symbol don't work together
- From: "H. J. Lu" <hjl at lucon dot org>
- To: Roland McGrath <roland at redhat dot com>
- Cc: GNU C Library <libc-alpha at sources dot redhat dot com>,binutils at sources dot redhat dot com
- Date: Mon, 31 Mar 2003 09:33:45 -0800
- Subject: RFC: STO_COPY again: Re: Copy relocation and protected symbol don't work together
- References: <20030326161114.A13101@lucon.org> <200303290232.h2T2WN102012@magilla.sf.frob.com>
On Fri, Mar 28, 2003 at 06:32:23PM -0800, Roland McGrath wrote:
> I think either prohibiting such references or producing text relocs is the
> only workable answer. If a variable is marked protected, the compiler may
Since ld doesn't know if protected symbols will be involved or
not at the run-time, are you suggesting ld should disallow copy
relocation or DT_TEXTREL for all dynamic executables in order to
properly support protected symbols? I don't think it is a good idea.
> produce GOT-relative or PC-relative references that won't have any external
> reference when linked into a DSO. So even if the copy relocs are treated
> specially, there may be no relocation in the DSO to be pointed at the
> executable's copy.
Since it is a run-time thing, we have to always use PIC like ia64.
I don't think people will like that for x86.
>
> I think it's also arguable that the spec says it must behave as it does
> now. The gABI doesn't say anything about copy relocs in the specification
> of the STV_PROTECTED behavior. I have not seen a version of a psABI that
> is as recent as the gABI that I can read; I think the old i386 one I've
> found predates the visibility additions and so obviously doesn't mention
> the issue in the specification of copy relocs. The specification is in
> terms of the symbol table, and doesn't allow any special case in which a
> DSO's protected symbols are searched for elsewhere.
That is true. How about this patch? 0x80 in st_other has already
been used by alpha. It is like we reuse a bit in st_other. Compared
with STT_COPY_OBJECT, it doesn't have binary compatibility problem.
H.J.
---
bfd/
2003-03-28 H.J. Lu <hjl at gnu dot org>
* elf32-i386.c (elf_i386_adjust_dynamic_symbol): Set STO_COPY
for R_386_COPY relocation.
include/elf/
2003-03-28 H.J. Lu <hjl at gnu dot org>
* common.h (STO_COPY): New.
--- binutils/bfd/elf32-i386.c.copy 2003-03-07 16:44:56.000000000 -0800
+++ binutils/bfd/elf32-i386.c 2003-03-28 11:21:26.000000000 -0800
@@ -1493,6 +1493,7 @@ elf_i386_adjust_dynamic_symbol (info, h)
{
htab->srelbss->_raw_size += sizeof (Elf32_External_Rel);
h->elf_link_hash_flags |= ELF_LINK_HASH_NEEDS_COPY;
+ h->other |= STO_COPY;
}
/* We need to figure out the alignment required for this symbol. I
--- binutils/include/elf/common.h.copy 2003-01-17 09:49:09.000000000 -0800
+++ binutils/include/elf/common.h 2003-03-28 11:08:29.000000000 -0800
@@ -427,6 +427,10 @@ Foundation, Inc., 59 Temple Place - Suit
#define ELF32_ST_VISIBILITY ELF_ST_VISIBILITY
#define ELF64_ST_VISIBILITY ELF_ST_VISIBILITY
+/* Use one bit in the st_other field to indicate if a definition comes
+ from a copy relocation. It is used by a copy relocation against a
+ protected symbol. */
+#define STO_COPY 0x80
#define STN_UNDEF 0 /* Undefined symbol index */