| Message ID | ydd8tio22pc.fsf@CeBiTec.Uni-Bielefeld.DE |
|---|---|
| State | New |
| Headers | show |
On Aug 12, 2017, at 9:03 AM, Rainer Orth <ro@CeBiTec.Uni-Bielefeld.DE> wrote: > > The new gcc.dg/pie-static-[12].c testcases FAIL on several systems: > > * Solaris 11.4 has PIE support, but lacks static libc, libm > > * Linux without the static libc, libm installed > > The following patch fixes this by requiring both PIE and -static > support. > > Tested with the appropriate runtest invocations on i386-pc-solaris2.11 > and x86_64-pc-linux-gnu (where the tests come up as UNSUPPORTED; I don't > have a Linux system with static libc/libm installed), installed on > mainline. > > The tests also FAIL on Darwin/x86_64, but the failure mode is different: > for -static, the executable is linked with -lcrt0.o (done this way to > locate crt0.o in the linker's search path, cf. config/darwin.h > (STARTFILE_SPEC)), but neither on Darwin 11 nor on Darwin 17 could I > find where crt0.o would come from, so I've left this part alone. darwin isn't exactly like other systems. There is no crt0.o and static is more special than you can imagine. There was once 1 program that did a static link, but one was exceptionally special. Indeed, one way to implement it would be as a request option, and then ignore the parts that don't make sense for the platform. In that case, -static-libgcc and friends might be the end semantics.
Hi Mike, > On Aug 12, 2017, at 9:03 AM, Rainer Orth <ro@CeBiTec.Uni-Bielefeld.DE> wrote: >> >> The new gcc.dg/pie-static-[12].c testcases FAIL on several systems: >> >> * Solaris 11.4 has PIE support, but lacks static libc, libm >> >> * Linux without the static libc, libm installed >> >> The following patch fixes this by requiring both PIE and -static >> support. >> >> Tested with the appropriate runtest invocations on i386-pc-solaris2.11 >> and x86_64-pc-linux-gnu (where the tests come up as UNSUPPORTED; I don't >> have a Linux system with static libc/libm installed), installed on >> mainline. >> >> The tests also FAIL on Darwin/x86_64, but the failure mode is different: >> for -static, the executable is linked with -lcrt0.o (done this way to >> locate crt0.o in the linker's search path, cf. config/darwin.h >> (STARTFILE_SPEC)), but neither on Darwin 11 nor on Darwin 17 could I >> find where crt0.o would come from, so I've left this part alone. > > darwin isn't exactly like other systems. There is no crt0.o and static is > more special than you can imagine. There was once 1 program that did a > static link, but one was exceptionally special. > > Indeed, one way to implement it would be as a request option, and then > ignore the parts that don't make sense for the platform. In that case, > -static-libgcc and friends might be the end semantics. All this begs the question why on earth would darwin.h (STARTFILE_SPEC) accept -static and try to link libcrt0.o it the latter doesn't exist. However, I've just found that the bundled clang on Darwin 11 does the same (and fails in the same way: "ld: library not found for -lcrt0.o"). Rainer
Hi Rainer, > On 28 Aug 2017, at 16:33, Rainer Orth <ro@CeBiTec.Uni-Bielefeld.DE> wrote: > > Hi Mike, > >> On Aug 12, 2017, at 9:03 AM, Rainer Orth <ro@CeBiTec.Uni-Bielefeld.DE> wrote: >>> >>> The new gcc.dg/pie-static-[12].c testcases FAIL on several systems: >>> >>> * Solaris 11.4 has PIE support, but lacks static libc, libm >>> >>> * Linux without the static libc, libm installed >>> >>> The following patch fixes this by requiring both PIE and -static >>> support. >>> >>> Tested with the appropriate runtest invocations on i386-pc-solaris2.11 >>> and x86_64-pc-linux-gnu (where the tests come up as UNSUPPORTED; I don't >>> have a Linux system with static libc/libm installed), installed on >>> mainline. >>> >>> The tests also FAIL on Darwin/x86_64, but the failure mode is different: >>> for -static, the executable is linked with -lcrt0.o (done this way to >>> locate crt0.o in the linker's search path, cf. config/darwin.h >>> (STARTFILE_SPEC)), but neither on Darwin 11 nor on Darwin 17 could I >>> find where crt0.o would come from, so I've left this part alone. >> >> darwin isn't exactly like other systems. There is no crt0.o and static is >> more special than you can imagine. There was once 1 program that did a >> static link, but one was exceptionally special. >> >> Indeed, one way to implement it would be as a request option, and then >> ignore the parts that don't make sense for the platform. In that case, >> -static-libgcc and friends might be the end semantics. > > All this begs the question why on earth would darwin.h (STARTFILE_SPEC) > accept -static and try to link libcrt0.o it the latter doesn't exist. > > However, I've just found that the bundled clang on Darwin 11 does the > same (and fails in the same way: "ld: library not found for -lcrt0.o”). I think it’s because when one is bringing up the system, then one does (or at least used to) have a static libc/crt set. Thus the compiler did/does need to support it for that case. I’ve not done a kernel bootstrap since ≈ Darwin9 era, so things might have changed and this could be history leaking through. Iain Iain Sandoe CodeSourcery / Mentor Embedded / Siemens
Hi Iain, >> All this begs the question why on earth would darwin.h (STARTFILE_SPEC) >> accept -static and try to link libcrt0.o it the latter doesn't exist. >> >> However, I've just found that the bundled clang on Darwin 11 does the >> same (and fails in the same way: "ld: library not found for -lcrt0.o”). > > I think it’s because when one is bringing up the system, then one does (or > at least used to) have a static libc/crt set. > Thus the compiler did/does need to support it for that case. I’ve not done > a kernel bootstrap since ≈ Darwin9 era, so things might have changed and > this could be history leaking through. I've now found the following statement: https://developer.apple.com/library/content/qa/qa1118/_index.html effectively declaring statically linked binaries unsupported (same as newer Solaris versions do, btw.). I've now checked clang from Darwin 17 (Xcode 9 Beta) and it behaves the same. I've found the following in clang sources } else { if (Args.hasArg(options::OPT_static) || Args.hasArg(options::OPT_object) || Args.hasArg(options::OPT_preload)) { CmdArgs.push_back("-lcrt0.o"); in lib/Driver/ToolChains/Darwin.cpp (Darwin::addStartObjectFileArgs). Several comments seem to indicate that most of this is just a straightforward translation of GCC's Darwin specs to C++ ;-) Overall, mostly a historical artifact these days, it seems. Rainer
> On 29 Aug 2017, at 09:56, Rainer Orth <ro@CeBiTec.Uni-Bielefeld.DE> wrote: >>> All this begs the question why on earth would darwin.h (STARTFILE_SPEC) >>> accept -static and try to link libcrt0.o it the latter doesn't exist. >>> >>> However, I've just found that the bundled clang on Darwin 11 does the >>> same (and fails in the same way: "ld: library not found for -lcrt0.o”). >> >> I think it’s because when one is bringing up the system, then one does (or >> at least used to) have a static libc/crt set. >> Thus the compiler did/does need to support it for that case. I’ve not done >> a kernel bootstrap since ≈ Darwin9 era, so things might have changed and >> this could be history leaking through. > > I've now found the following statement: > > https://developer.apple.com/library/content/qa/qa1118/_index.html > effectively declaring statically linked binaries unsupported (same as > newer Solaris versions do, btw.). It's been unsupported in user-space for as long as I recall … > I've now checked clang from Darwin 17 (Xcode 9 Beta) and it behaves the > same. I've found the following in clang sources > > } else { > if (Args.hasArg(options::OPT_static) || > Args.hasArg(options::OPT_object) || > Args.hasArg(options::OPT_preload)) { > CmdArgs.push_back("-lcrt0.o"); > > in lib/Driver/ToolChains/Darwin.cpp (Darwin::addStartObjectFileArgs). > Several comments seem to indicate that most of this is just a > straightforward translation of GCC's Darwin specs to C++ ;-) > > Overall, mostly a historical artifact these days, it seems. possibly, indeed - but ... … as noted above. when bringing the system up from scratch (i.e. bootstrapping the kernel, and associated stuff) there’s (or at least used to be) a phase where some tools _are_ built with static linkage - and part of that process involves building the crt0 + a statically-linkable libc. That the code is still present in clang, suggests this could still be the case (although the ‘just left in there by accident’ explanation is possible too, I will try to query someone for a definite answer). In any case, we might as well just skip such tests (or xfail them) on Darwin, that’s a correct reflection of the user-land expectation. Iain Sandoe CodeSourcery / Mentor Embedded / Siemens
# HG changeset patch # Parent ab504e0e88e6aee93d2910b5ad66fe16cd5414f9 Require -static support in gcc.dg/pie-static-[12].c diff --git a/gcc/testsuite/gcc.dg/pie-static-1.c b/gcc/testsuite/gcc.dg/pie-static-1.c --- a/gcc/testsuite/gcc.dg/pie-static-1.c +++ b/gcc/testsuite/gcc.dg/pie-static-1.c @@ -1,4 +1,6 @@ -/* { dg-do run { target pie } } */ +/* { dg-do run } */ +/* { dg-require-effective-target static } */ +/* { dg-require-effective-target pie } */ /* { dg-options "-static -fpie -pie" } */ int main(void) diff --git a/gcc/testsuite/gcc.dg/pie-static-2.c b/gcc/testsuite/gcc.dg/pie-static-2.c --- a/gcc/testsuite/gcc.dg/pie-static-2.c +++ b/gcc/testsuite/gcc.dg/pie-static-2.c @@ -1,4 +1,6 @@ -/* { dg-do run { target pie } } */ +/* { dg-do run } */ +/* { dg-require-effective-target pie } */ +/* { dg-require-effective-target static } */ /* { dg-options "-fpie -pie -static" } */ int main(void)