This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH] Pull in ld.so for libresolv
On Wed, 21 Sep 2011, Roland McGrath wrote:
> > No, the -fstack-protector is not there because of implicit options. It's
> > currently added to CFLAGS-libresolv in resolv/Makefile.
>
> I see. Well, using __stack_chk_guard from ld.so is not a good idea. It
> won't be initialized, because that's only done if THREAD_SET_STACK_GUARD
> isn't defined. I think you really just need to configure your compiler
Rather, it won't be exported at all.
> correctly. See TARGET_LIBC_PROVIDES_SSP and the configure check that
> sets it.
This is nothing to do with the configure test. This is about some
architectures having THREAD_SET_STACK_GUARD defined in tls.h and having
stack-protector patterns in GCC that do not need __stack_check_guard and
__stack_check_guard not being exported from ld.so on those architectures,
and other architectures not having THREAD_SET_STACK_GUARD defined in
tls.h, not having such patterns in GCC and exporting __stack_check_guard
from ld.so. (For example, SH is a libc architecture of the latter type.)
Starting to define THREAD_SET_STACK_GUARD on an existing target would
break the ABI that expects __stack_chk_guard to be exported, quite apart
from issues of compatibility with different compiler versions used to
build glibc.
Linking in ld.so should be unconditionally safe - ld.so is going to be
loaded into the process using libresolv anyway - and while it could be
conditioned on a grep of tls.h for THREAD_SET_STACK_GUARD that seems
excess complexity, while making architectures declare separately in their
makefiles whether they need ld.so here would be undue duplication. I
suppose if you want it to be conditional then
LDLIBS-resolv.so += $(as-needed) $(elfobjdir)/ld.so $(no-as-needed)
(untested) would be the obvious way of only linking it in if required.
It would also accord with how normal shared libraries are linked using the
libc.so linker script which has AS_NEEDED ( $(slibdir)/$(rtld-installed-name) )
in it - and in general I think that if a shared object installed by glibc
is *not* linked in the same way as a library built after glibc is
installed (with the shared libc, libc_nonshared and AS_NEEDED ( ld.so )),
*that* is the deviation that needs justification on the basis of special
properties of the shared object in question.
--
Joseph S. Myers
joseph@codesourcery.com