This is the mail archive of the
binutils@sources.redhat.com
mailing list for the binutils project.
RFC: Add STO_COPY (Re: Copy relocation and protected symbol don't work together)
On Thu, Mar 27, 2003 at 04:37:53PM -0800, H. J. Lu wrote:
> 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.
>
Or we can use one bit in st_other for it.
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 0x20
#define STN_UNDEF 0 /* Undefined symbol index */