Symbol weirdness with static linking

[Kostik Belousov]

On Thu, Apr 20, 2006 at 01:48:22PM +0200, Jeremie Le Hen wrote:
> Hi hackers,
> 
> I created a library (libssp) which is to be linked in the same time as
> libgcc (GCC's LIBGCC_SPEC [1]).  This library is intended to provide the
> required symbols for ProPolice/SSP (Stack-Smashing Protector) which GCC
> references whenever it has to protect a function.
> 
> This works almost perfectly but in one edge case : some programs
> are so "simple" (IOW have no stack-based buffer) that GCC does not
> feel the need to put any reference to the above symbols.  For instance,
> bin/echo and bin/mkdir are such programs.
> 
> When libssp is linked dynamically, this is not a problem.  However, if
> I use NO_DYNAMICROOT when building world, ld(1) complains that it does not
> find the "syslog" symbol [2].  It happens that libssp uses syslog(3), but
> since libssp won't be in the resulting executable, I don't understand
> why ld(1) complains.
> 
> OTOH, programs which do have a reference to ProPolice symbols compile
> without any problem.
> 
> Even weirder, while there are other calls to libc functions in libssp
> - such as open(2), sigfillset(3) or sigprocmask(2) - if I comment out
> the call to syslog(3), ld(1) does not complain any longer.  What is
> so special with libc's "syslog" symbol ?  I don't understand what is
> the difference here between, the "syslog" symbol and, say, the "sigfilset"
> symbol (which is not used in echo(1) either).
> 
> For the sake of completeness, I added the output of some objdump(1)
> outputs here :
> 
> /usr/obj/usr/src/bin/echo/echo.o:
> http://tataz.chchile.org/~tataz/symbol_weirdness/objdump-t_echo.txt.gz
> 
> /usr/obj/usr/src/tmp/usr/lib/libc.a:
> http://tataz.chchile.org/~tataz/symbol_weirdness/objdump-t_libc.txt.gz
> 
> /usr/obj/usr/src/tmp/usr/lib/libssp.a:
> http://tataz.chchile.org/~tataz/symbol_weirdness/objdump-t_libssp.txt.gz
> 
> 
> Thank you.
> Regards,
> 
> 
> [1]
> #define LIBGCC_SPEC "%{shared: -lgcc_pic -lssp_pic} %{!shared: %{!pg: -lgcc -lssp} %{pg: -lgcc_p -lssp_p}}"
> 
> 
> [2]
> ===> bin/echo (all)
> cc -O2 -fno-strict-aliasing -pipe -march=pentium-m -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -c /usr/src/bin/echo/echo.c
> cc -O2 -fno-strict-aliasing -pipe -march=pentium-m -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls  -v -static -o echo echo.o
> Using built-in specs.
> Configured with: FreeBSD/i386 system compiler
> Thread model: posix
> gcc version 3.4.4 [FreeBSD] 20050518
>  /usr/obj/usr/src/tmp/usr/bin/ld -V -Bstatic -o echo /usr/obj/usr/src/tmp/usr/lib/crt1.o /usr/obj/usr/src/tmp/usr/lib/crti.o /usr/obj/usr/src/tmp/usr/lib/crtbegin.o -L/usr/obj/usr/src/tmp/usr/lib echo.o -lgcc -lssp -lc -lgcc -lssp /usr/obj/usr/src/tmp/usr/lib/crtend.o /usr/obj/usr/src/tmp/usr/lib/crtn.o
> GNU ld version 2.15 [FreeBSD] 2004-05-23
>   Supported emulations:
>    elf_i386_fbsd
> /usr/obj/usr/src/tmp/usr/lib/libssp.a(ssp.o)(.text+0xe8): In function `__stack_smash_handler':
> : undefined reference to `syslog'
> *** Error code 1
> 
> -- 
> Jeremie Le Hen
> < jeremie at le-hen dot org >< ttz at chchile dot org >

It seems that you rebuilt world with CFLAGS -fstack-protector,
since your libc has references to the symbols like __stack_smash_handler.
As result, when linking with sequence -lgcc -lssp -lc -lgcc -lssp,
and no references from the main object,
references from libc causes objects from _second_ instance of -lssp to
be pulled into the link. Since libraries are scanned sequentially,
this object from libssp has no way to get required dependencies
from libc.

What makes syslog(3) special is that corresponding object from libc,
syslog.o, requires __stack_smash_handler, while objects for mentioned
syscalls do not.

Probably, another -lc after -lssp will change the situation. But
I'm not sure would it be enough or not.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20060420/728c5ca5/attachment.pgp