This is the mail archive of the
libc-alpha@sources.redhat.com
mailing list for the glibc project.
RFC: Add STT_COPY_OBJECT (Re: Copy relocation and protected symbol don't work together)
On Wed, Mar 26, 2003 at 04:11:14PM -0800, H. J. Lu wrote:
> On Wed, Mar 26, 2003 at 01:40:25PM -0800, H. J. Lu wrote:
> > On Wed, Mar 26, 2003 at 12:29:09PM -0800, H. J. Lu wrote:
> > > glibc/ld don't handle addresss of some protected symbols right. Here is
> > > a testcase for glibc. I am not certain where the bug is. It could be
> > > in glibc and/or ld.
> > >
> >
> > Here is an update for my last patch. It turns out we aren't testing
> > addresses of variables at all. We just test their values which happen
> > to be addresses of some strings. This patch fixes the testcase. It
> > is a glibc bug. I will post a patch later.
> >
>
> The bug is quite tricky. Here is a testcase:
>
> # make
> gcc -O -c main.c
> gcc -O -fPIC -c shared.c
> gcc -shared -o libfoo.so shared.o
> gcc -o foo main.o libfoo.so -Wl,-rpath,.
> for f in foo; do echo "Running: $f"; ./$f; \
> if [ $? != 0 ]; then echo Failed; fi; done
> Running: foo
> Data address: 0x8049924 != Data address from DSO: 0x400187f4
> Data: 100 != Data from DSO: 10
>
> The problem is for a symbol with copy relocation, the main executable
> has
>
> 3: 08049924 4 OBJECT GLOBAL DEFAULT 22 shared_data
> 87: 08049924 4 OBJECT GLOBAL DEFAULT 22 shared_data
>
> in symbol table and
>
> 08049924 00000305 R_386_COPY 08049924 shared_data
>
> in relocation entries. When ld.so looks up for a protected shared_data
> for libfoo.so, it doesn't know if the definition of shared_data in
> executable comes from R_386_COPY by just looking at the symbol table.
> I see we can do one of 2 things:
>
> 1. ld.so checks all relocation entries for R_386_COPY.
> 2. ld doesn't create R_386_COPY for protected definion, which will set
> DT_TEXTREL in executable.
>
> I don't like either one very much. If I have to choose, I will go with
> #2. Is there anything else we can do? Can ld put shared_data in a
> special .copy section so that ld.so can know it comes from R_386_COPY?
>
We can also add STT_COPY_OBJECT for this problem. Then the dynamic
linker can check STT_COPY_OBJECT for definion from copy relocation.
H.J.
----
bfd/
2003-03-27 H.J. Lu <hjl at gnu dot org>
* elf32-i386.c (elf_i386_adjust_dynamic_symbol): Set type to
STT_COPY_OBJECT for R_386_COPY relocation.
include/elf/
2003-03-27 H.J. Lu <hjl at gnu dot org>
* i386.h (STT_COPY_OBJECT): New.
--- binutils/bfd/elf32-i386.c.copy 2003-03-07 16:44:56.000000000 -0800
+++ binutils/bfd/elf32-i386.c 2003-03-27 15:19:24.000000000 -0800
@@ -1493,6 +1493,9 @@ 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;
+
+ BFD_ASSERT (h->type == STT_OBJECT);
+ h->type = STT_COPY_OBJECT;
}
/* We need to figure out the alignment required for this symbol. I
--- binutils/include/elf/i386.h.copy 2002-09-20 22:12:10.000000000 -0700
+++ binutils/include/elf/i386.h 2003-03-27 14:50:07.000000000 -0800
@@ -20,6 +20,10 @@
#ifndef _ELF_I386_H
#define _ELF_I386_H
+/* It resembles STT_OBJECT, but the symbol is created by a copy
+ relocation. */
+#define STT_COPY_OBJECT STT_LOPROC
+
#include "elf/reloc-macros.h"
START_RELOC_NUMBERS (elf_i386_reloc_type)