An ELF linker bug?

An ELF linker bug?

[H.J. Lu]

Here is a simple test. "f1" should print out "foo". Under UnixWare,
it worked fine. But gas-950822 failed to pick up the strong "foo".
Also Solaris 2.3 got it wrong.


-- 
H.J. Lu
NYNEX Science and Technology, Inc.			hjl@nynexst.com
----
#!/bin/sh
# This is a shell archive (produced by GNU sharutils 4.1).
# To extract the files from this archive, save it to some FILE, remove
# everything before the `!/bin/sh' line above, then type `sh FILE'.
#
# Made on 1995-09-10 21:30 EDT by <hjl@didi>.
# Source directory was `/home/hjl/bugs/ld/weak1'.
#
# Existing files will *not* be overwritten unless `-c' is specified.
#
# This shar contains:
# length mode       name
# ------ ---------- ------------------------------------------
#    262 -rw-r--r-- Makefile
#     97 -rw-r--r-- bar.c
#     51 -rw-r--r-- foo.c
#     22 -rw-r--r-- main.c
#
touch -am 1231235999 $$.touch >/dev/null 2>&1
if test ! -f 1231235999 && test -f $$.touch; then
  shar_touch=touch
else
  shar_touch=:
  echo
  echo 'WARNING: not restoring timestamps.  Consider getting and'
  echo "installing GNU \`touch', distributed in GNU File Utilities..."
  echo
fi
rm -f 1231235999 $$.touch
#
# ============= Makefile ==============
if test -f 'Makefile' && test X"$1" != X"-c"; then
  echo 'x - skipping Makefile (file already exists)'
else
  echo 'x - extracting Makefile (text)'
  sed 's/^X//' << 'SHAR_EOF' > 'Makefile' &&
SRCS= foo.c bar.c
SRCS= bar.c foo.c
OBJS=$(SRCS:.c=.o)
AR=ar
CFLAGS=
CC=gcc
RANLIB =ranlib
X
X.c.o:
X	$(CC) $(CFLAGS) -c $<
X
all: f1
X
f1: libfoo.a
X	$(CC) -o $@ main.c -L. -lfoo
X
libfoo.a:$(OBJS)
X	$(AR) ucvr $@ $(OBJS)
X	$(RANLIB) $@
X
clean:
X	-rm -f *.o *.a f1 f2 f3
SHAR_EOF
  $shar_touch -am 0910211995 'Makefile' &&
  chmod 0644 'Makefile' ||
  echo 'restore of Makefile failed'
  shar_count="`wc -c < 'Makefile'`"
  test 262 -eq "$shar_count" ||
    echo "Makefile: original size 262, current size $shar_count"
fi
# ============= bar.c ==============
if test -f 'bar.c' && test X"$1" != X"-c"; then
  echo 'x - skipping bar.c (file already exists)'
else
  echo 'x - extracting bar.c (text)'
  sed 's/^X//' << 'SHAR_EOF' > 'bar.c' &&
#include <stdio.h>
X
/*#pragma weak bar */
#pragma weak foo = bar
X
bar ()
{
X  printf ("bar\n");
}
SHAR_EOF
  $shar_touch -am 0910211995 'bar.c' &&
  chmod 0644 'bar.c' ||
  echo 'restore of bar.c failed'
  shar_count="`wc -c < 'bar.c'`"
  test 97 -eq "$shar_count" ||
    echo "bar.c: original size 97, current size $shar_count"
fi
# ============= foo.c ==============
if test -f 'foo.c' && test X"$1" != X"-c"; then
  echo 'x - skipping foo.c (file already exists)'
else
  echo 'x - extracting foo.c (text)'
  sed 's/^X//' << 'SHAR_EOF' > 'foo.c' &&
#include <stdio.h>
X
foo ()
{
X  printf ("foo\n");
}
SHAR_EOF
  $shar_touch -am 0910211695 'foo.c' &&
  chmod 0644 'foo.c' ||
  echo 'restore of foo.c failed'
  shar_count="`wc -c < 'foo.c'`"
  test 51 -eq "$shar_count" ||
    echo "foo.c: original size 51, current size $shar_count"
fi
# ============= main.c ==============
if test -f 'main.c' && test X"$1" != X"-c"; then
  echo 'x - skipping main.c (file already exists)'
else
  echo 'x - extracting main.c (text)'
  sed 's/^X//' << 'SHAR_EOF' > 'main.c' &&
main ()
{
X  foo ();
}
SHAR_EOF
  $shar_touch -am 0910211595 'main.c' &&
  chmod 0644 'main.c' ||
  echo 'restore of main.c failed'
  shar_count="`wc -c < 'main.c'`"
  test 22 -eq "$shar_count" ||
    echo "main.c: original size 22, current size $shar_count"
fi
exit 0

Re: An ELF linker bug?

[Ian Lance Taylor]

   From: hjl@nynexst.com (H.J. Lu)
   Date: Sun, 10 Sep 1995 21:33:01 -0400 (EDT)

   Here is a simple test. "f1" should print out "foo". Under UnixWare,
   it worked fine. But gas-950822 failed to pick up the strong "foo".
   Also Solaris 2.3 got it wrong.

I think this case is undefined.  You are defining a symbol twice in an
archive.  It does not matter that one definition is weak and one is
normal.  A weak definition is pulled in from an archive just as a
normal one is.  This case is equivalent to defining the same symbol in
two different object files and including them both in an archive: you
can not predict which object file will be included in the final link.

Ian