An ld bug?

An ld bug?

[H.J. Lu]

Hi,

It seems gas-950822 doesn't treat common symbols right. Does the newer
snapshot still have this bug? BTW, I tested it under i486-linux.

Thanks.


-- 
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-10-02 23:51 EDT by <hjl@didi>.
# Source directory was `/home/hjl/bugs/ld/common'.
#
# Existing files will *not* be overwritten unless `-c' is specified.
#
# This shar contains:
# length mode       name
# ------ ---------- ------------------------------------------
#    273 -rw-r--r-- Makefile
#     14 -rw-r--r-- bar.c
#     71 -rw-r--r-- x.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
RANLIB =echo
X
X.c.o:
X	$(CC) $(CFLAGS) -c $<
X
all: f1
X
f1: libbar.a
X	$(CC) -o $@ x.c -L. -lbar
X
libbar.a:$(OBJS)
X	$(AR) ucvr $@ $(OBJS)
X	$(RANLIB) $@
X
clean:
X	-rm -f *.o *.a f1 f2 f3
SHAR_EOF
  $shar_touch -am 1002235095 'Makefile' &&
  chmod 0644 'Makefile' ||
  echo 'restore of Makefile failed'
  shar_count="`wc -c < 'Makefile'`"
  test 273 -eq "$shar_count" ||
    echo "Makefile: original size 273, 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' &&
int bar = 10;
SHAR_EOF
  $shar_touch -am 1002223695 'bar.c' &&
  chmod 0644 'bar.c' ||
  echo 'restore of bar.c failed'
  shar_count="`wc -c < 'bar.c'`"
  test 14 -eq "$shar_count" ||
    echo "bar.c: original size 14, current size $shar_count"
fi
# ============= x.c ==============
if test -f 'x.c' && test X"$1" != X"-c"; then
  echo 'x - skipping x.c (file already exists)'
else
  echo 'x - extracting x.c (text)'
  sed 's/^X//' << 'SHAR_EOF' > 'x.c' &&
#include <stdio.h>
X
int bar;
X
main ()
{
X  printf ("bar: %d\n", bar);
}
SHAR_EOF
  $shar_touch -am 1002224095 'x.c' &&
  chmod 0644 'x.c' ||
  echo 'restore of x.c failed'
  shar_count="`wc -c < 'x.c'`"
  test 71 -eq "$shar_count" ||
    echo "x.c: original size 71, current size $shar_count"
fi
exit 0

Re: An ld bug?

[Ian Lance Taylor]

   From: hjl@nynexst.com (H.J. Lu)

   It seems gas-950822 doesn't treat common symbols right. Does the newer
   snapshot still have this bug? BTW, I tested it under i486-linux.

It only takes you a minute to note what you think is incorrect about
the program.  Please do that, rather than making me figure out what
the problem is.  Thanks.

In this case, I assume that you think that the common symbol in the
object file should cause the object in the archive to be brought in.
That's the way in works in a.out, but it is not the way it works in
ELF.  In ELF, objects are only brought in from archives to fill
references by undefined symbols.

However, interestingly, I tested the program on Irix 5, UnixWare, and
Solaris, and, on Solaris, it works the way it does in a.out.  I assume
this is for SunOS compatibility.  It happens to contradict the Solaris
linker documentation: ``For an archive library, only those routines
defining an unresolved external reference are loaded.''

Ian

Re: An ld bug?

[H.J. Lu]

> 
>    From: hjl@nynexst.com (H.J. Lu)
> 
>    It seems gas-950822 doesn't treat common symbols right. Does the newer
>    snapshot still have this bug? BTW, I tested it under i486-linux.
> 
> It only takes you a minute to note what you think is incorrect about
> the program.  Please do that, rather than making me figure out what
> the problem is.  Thanks.

Sorry for that.

> 
> In this case, I assume that you think that the common symbol in the
> object file should cause the object in the archive to be brought in.
> That's the way in works in a.out, but it is not the way it works in
> ELF.  In ELF, objects are only brought in from archives to fill
> references by undefined symbols.
> 
> However, interestingly, I tested the program on Irix 5, UnixWare, and
> Solaris, and, on Solaris, it works the way it does in a.out.  I assume
> this is for SunOS compatibility.  It happens to contradict the Solaris
> linker documentation: ``For an archive library, only those routines
> defining an unresolved external reference are loaded.''
> 

From my Solaris 2.3 linker manual, on page 12 regarding "Archive
Processing", it says the link-editor will extract a relocatable object
from an archive if it contains a data symbol definition that
satisfies a common symbol definition.

I think that makes sense. Maybe it has been changed in Solaris 2.4/2.5.

Thanks.


-- 
H.J. Lu
NYNEX Science and Technology, Inc.			hjl@nynexst.com

Re: An ld bug?

[David S. Miller]

   From: hjl@nynexst.com (H.J. Lu)
   Date: Tue, 3 Oct 95 11:20:49 EDT

   >From my Solaris 2.3 linker manual, on page 12 regarding "Archive
   Processing", it says the link-editor will extract a relocatable object
   from an archive if it contains a data symbol definition that
   satisfies a common symbol definition.

   I think that makes sense. Maybe it has been changed in Solaris 2.4/2.5.

The linker provided with the new beta solaris2.5 SUNWspro C4.0 gives
the elf behavior you are expecting where only referenced objects get
extracted from an archive, for what it's worth...

Later,
David S. Miller
davem@caip.rutgers.edu