From mboxrd@z Thu Jan  1 00:00:00 1970
From: Jeffrey A Law <law@cygnus.com>
To: Jason Merrill <jason@cygnus.com>
Cc: egcs@cygnus.com, gcc2@cygnus.com
Subject: Re: We still need those old frame functions in libgcc.a 
Date: Tue, 16 Dec 1997 18:49:00 -0000
Message-id: <7801.882321512@hurl.cygnus.com>
References: <u9afe0ztxj.fsf@yorick.cygnus.com>
X-SW-Source: 1997-12/msg00923.html

  In message < u9afe0ztxj.fsf@yorick.cygnus.com >you write:
  > > If we leave -lgcc out, linker will leave __register_frame
  > > undefined in shared libraries, we have to keep
  > > __register_frame in libgcc.a in new gcc. Otherwise, during
  > > the link time, ld will find undefined __register_frame
  > > referenced by shared libraries when new gcc is used.
  > 
  > So don't leave out -lgcc.
Right.  HJ's even sent me a patch to fix this for sparc-linux.

ptx4 & sco5 are still broken in this regard according to HJ.  



  > > B. We have to keep __register_frame in libgcc.a.
  > 
  > > 1. Say binary "foo" needs libbar.so, since __register_frame
  > > is in libbar.so, linker will leave __register_frame
  > > undefined in foo and the dynamic linker will find
  > > __register_frame in libbar.so at the runtime.
  > 
  > Why would the linker add undefined symbols that are not used by foo, but
  > rather shared libraries linked with foo?  I don't think any linker actually
  > works that way.  libbar.so can look out for its own undefined symbols.
What I think HJ was trying to say was that no definition of
__register_frame will exist in foo since it can be satisfied from the copy
that existed in libbar.so when foo was originally linked against libbar.so.

This is how the GNU linker works:

First, we'll create a shared library which contains a reference to __divdi3:

[law@ralph /puke/law] cat foo.c
blah ()
{
long long x, y = 1;
return x / y;
}

[law@ralph /puke/law] gcc -fPIC -o libfoo.so foo.c -shared
[law@ralph /puke/law] nm libfoo.so | grep divdi3
000006a4 T __divdi3

Note the copy of __divdi3 in libfoo.so.

Now we'll create a main program that also uses __divdi3 and links
against libfoo.so:

[law@ralph /puke/law] gcc k.c -L./ -lfoo
[law@ralph /puke/law] ldd a.out
        libfoo.so => ./libfoo.so
        libc.so.5 => /lib/libc.so.5
[law@ralph /puke/law] nm a.out | grep divdi3
         U __divdi3
[law@ralph /puke/law] ./a.out

Note that a.out depends on libfoo and that "__divdi3" is considered
undefined in a.out since it will be satisfied by the libfoo.so
shared library.  Note that the program successfully runs.

Now we change libfoo.sl so that it no longer has a reference to __divdi3:

[law@ralph /puke/law] cat foo.c
blah ()
{
long long x, y = 1;
return x * y;
}

[law@ralph /puke/law] gcc -fPIC -o libfoo.so foo.c -shared
[law@ralph /puke/law] nm libfoo.so | grep divdi3

Now we we try to run a.out, which depends on libfoo.so it will fail:

[law@ralph /puke/law] ./a.out
./a.out: can't resolve symbol '__divdi3'



We run into basically the same situation with __register_frame.

jeff