Copy relocation and protected symbol don't work together

["H. J. Lu" <hjl at lucon dot org>]

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?


H.J.

Attachment: bug.tar.gz
Description: GNU Zip compressed data