Ther revert MR is here: https://gitlab.haskell.org/ghc/ghc/-/merge_requests/3714 It's kind of ironic that it's stuck in CI limbo, whereas the initial MR wasn't.
> I'm surprised gitlab presubmit merge did not detect the build breakage. So am I! As laid out, I believe a better solution is to have a mapping of symbols to potential carrying libraries, and have GHC know about that, when the linker tries to link arbitrary objects and encounters those symbols. Another strategy that Tamar employed to great success on the windows side, is to just increase the set of libraries GHC tries to load by default, and thus get rid of the annoying list of symbols in the RTS. I hope the above MR will pass now (after another rebase); and I can find some time to implement a better solution soon. Cheers, Moritz On Mon, Jul 20, 2020 at 4:28 PM Sergei Trofimovich <sly...@gmail.com> wrote: > > On Fri, 17 Jul 2020 10:45:37 +0800 > Moritz Angermann <moritz.angerm...@gmail.com> wrote: > > > Well, we actually *do* test for __SSP__ in HEAD: > > https://github.com/ghc/ghc/blob/master/rts/RtsSymbols.c#L1170 > > Which currently lists: > > #if !defined(mingw32_HOST_OS) && !defined(DYNAMIC) && > > (defined(_FORTIFY_SOURCE) || defined(__SSP__)) > > I believe it's a https://gitlab.haskell.org/ghc/ghc/-/issues/18442 > > It breaks for me as well. > > It triggers if one has gcc compiler with any of 2 properties: > > 1. gcc is built with --enable-default-ssp (sets __SSP__ for all compilations) > 2. gcc defaults to _FORTIFY_SOURCE > > Note that presence or absence of __stack_chk_guard is indicated > by neither of these and instead is present when gcc is built with > --enable-libssp (use gcc's __stack_* functions instead gcc's direct TLS > instructions with one glibc fallback.) > > Gentoo does both [1.] and [2.] by default. I believe Debian does at least > [2.] by default. I'm surprised gitlab presubmit merge did not detect the > build breakage. > > What do macros [1] and [2.] mean for glibc-linux: > > - _FORTIFY_SOURCE only affects glibc headers to change memcpy() > calls to memcpy_chk() to add overflow checks. It does not affect > symbol exports available by libc. __stack_* symbols are always present. > Parts of libc or other libraries we link ghc with coult already call > __stack_* > function as they could already be built with _FORTIFY_SOURCE. Regardless > of how ghc is being built: with _FORTIFY_SOURCE or without. > > - __SSP__ indicates code generation of stack canary placement by gcc > (-fstack-protector-* options, or default override with gcc's > --enable-default-ssp) > > If target is not a gcc's libssp target (a.k.a. --disable-libssp), a default > for all > linux-glibc targets) then gcc never uses -lssp and uses gcc's builtin > instructions > instead of __stack_chk_guard helpers. In this mode __stack_chk_guard is not > present in any libraries installed by gcc or glibc. The only symbol > provided by glibc > is __stack_chk_fail (which arguably should not be exposed at all as it's an > unusual contract between glibc/gcc: https://gcc.gnu.org/PR93509) > > --enable-libssp for gcc does bring in __stack_chk_guard. Library is present > and could > use __stack_chk_guard in libraries ghc depends on regardless of > -fstack-protector-* options used to build ghc. I believe --enable-libssp is > used only > on mingw. > > What I'm trying to say is that presence of __stack_chk_guard is orthogonal > to either __SSP__ define or _FORTIFY_SOURCE ghc uses today.. > > It's rather a function of how gcc toolchain was built: --enable-libssp or not. > > > But this seems to still be ill conceived. And while Simon is the only > > one I'm aware of, for whom this breaks we need to find a better > > solution. As such, we will revert the commits. > > > > Why do we do all this symbol nonsense in the RTS to begin with? It > > has to do with our static linker we have in GHC. Loading arbitrary > > archives, means we need to be able to resolve all kinds of symbols > > that objects might refer to. For regular dependencies this will work > > if the dependencies are listed in the package configuration file, the > > linker will know which dependencies to link. This get a bit annoying > > for libraries that the compiler will automagically provide. libgcc, > > libssp, librt, ... > > > > The solution so far was simply to have the RTS depend on these > > symbols, and keep a list of them around. That way when the linker > > built the RTS we'd get it to link all these symbols into the RTS, and > > we could refer to them in the linker. Essentially looking them up in > > the linked binary (ghc, or iserv). > > > > This is a rather tricky problem, and almost all solutions we came up > > with are annoying in one or more dimensions. After some discussion on > > IRC last night, we'll go forward trying the following solution: > > > > We'll keep a file in the lib folder (similar to the settings, > > llvm-targets, ...) that is essentially a lookup table of Symbol -> > > [Library]. If we encounter an unknown symbol, and we have it in our > > lookup table, we will try to load the named libraries, hoping for them > > to contain the symbol we are looking for. If everything fails we'll > > bail. > > > > For the example symbols that prompted this issue: (which are emitted > > when stack smashing protector hardening is enabled, which seems to be > > the default on most linux distributions today, which is likely why I > > couldn't reproduce this easily.) > > > > [("__stack_chk_guard", ["ssp"])] > > > > would tell the compiler to try to locate (through the usual library > > location means) the library called "ssp", if it encounters the symbol > > "__stack_chk_guard". > > > > Isn't this what the dynamic linker is supposed to solve? Why do we > > have to do all this on our own? Can't we just use the dynamic linker? > > Yes, and no. Yes we can use the dynamic linker, and we even do. But > > not all platforms have a working, or usable linker. iOS for example > > has a working dynamic linker, but user programs can't use it. muslc > > reports "Dynamic loading not supported" when calling dlopen on arm. > > > > Thus I'm reluctant to drop the static linker outright for the dynamic > > linker. > > > > Cheers, > > Moritz > > > > On Fri, Jul 17, 2020 at 2:45 AM Phyx <loneti...@gmail.com> wrote: > > > > > > But, where do you actually check for __SSP__ > > > > > > The guard just checks for not windows and not dynamic > > > https://github.com/ghc/ghc/commit/686e72253aed3880268dd6858eadd8c320f09e97#diff-03f5bc5a50fd8ae13e902782c4392c38R1157 > > > > > > shouldn't it just be checking for defined(__SSP__) instead? This check is > > > currently only correct if the distro has turned stack protector on by > > > default. > > > > > > > > > Regards, > > > Tamar > > > > > > On Thu, Jul 16, 2020 at 3:46 PM Moritz Angermann > > > <moritz.angerm...@gmail.com> wrote: > > >> > > >> I’ve tried to reproduce this and it turns out, I fail to. You are > > >> somehow building the rts either with _FORTYFY_SOURCE or __SSP__, but > > >> then your linker ends up not passing -lssp or the equivalent for your > > >> tool chain. > > >> > > >> At this point I’m tempted to add an additional ARM arch guard. While > > >> that would be conceptually wrong, it would reduce the cases where this > > >> could go wrong to a rarely used platform. Maybe @Ben Gamari has an idea? > > >> > > >> On Thu, 16 Jul 2020 at 10:25 PM, Simon Peyton Jones > > >> <simo...@microsoft.com> wrote: > > >>> > > >>> Moritz > > >>> > > >>> How’s it going getting this patch committed? > > >>> > > >>> It’s painful manually applying a fix, but then NOT committing that to > > >>> master by mistake > > >>> > > >>> > > >>> > > >>> Thanks > > >>> > > >>> s > > >>> > > >>> > > >>> > > >>> From: Moritz Angermann <moritz.angerm...@gmail.com> > > >>> Sent: 14 July 2020 12:14 > > >>> To: Simon Peyton Jones <simo...@microsoft.com> > > >>> Cc: ghc-devs@haskell.org > > >>> Subject: Re: HEAD doesn't build. Totally stalled. > > >>> > > >>> > > >>> > > >>> For some reason, you end up in the defined RTS_SSP_SYMBOLS, I believe > > >>> and then the RTS wants __stack_chk symbols. Which it can’t find when > > >>> linking. > > >>> > > >>> > > >>> > > >>> Replacing > > >>> > > >>> #if !defined(mingw32_HOST_OS) && !defined(DYNAMIC) > > >>> > > >>> #define RTS_SSP_SYMBOLS \ > > >>> > > >>> SymI_NeedsProto(__stack_chk_guard) \ > > >>> > > >>> SymI_NeedsProto(__stack_chk_fail) > > >>> > > >>> #else > > >>> > > >>> #define RTS_SSP_SYMBOLS > > >>> > > >>> #endif > > >>> > > >>> With just > > >>> > > >>> > > >>> > > >>> #define RTS_SSP_SYMBOLS > > >>> > > >>> > > >>> > > >>> Should do. I hope. > > >>> > > >>> > > >>> > > >>> Currently only on mobile phone :-/ > > >>> > > >>> > > >>> > > >>> Cheers, > > >>> > > >>> Moritz > > >>> > > >>> > > >>> > > >>> On Tue, 14 Jul 2020 at 7:06 PM, Simon Peyton Jones > > >>> <simo...@microsoft.com> wrote: > > >>> > > >>> thanks. What specifically do I comment out? > > >>> > > >>> > > >>> > > >>> From: Moritz Angermann <moritz.angerm...@gmail.com> > > >>> Sent: 14 July 2020 12:00 > > >>> To: Simon Peyton Jones <simo...@microsoft.com> > > >>> Cc: ghc-devs@haskell.org > > >>> Subject: Re: HEAD doesn't build. Totally stalled. > > >>> > > >>> > > >>> > > >>> This was my fault. Not sure why this wasn’t caught in CI. > > >>> > > >>> It’s due to the addition of the symbols here > > >>> > > >>> > > >>> > > >>> https://github.com/ghc/ghc/commit/686e72253aed3880268dd6858eadd8c320f09e97#diff-03f5bc5a50fd8ae13e902782c4392c38R1159 > > >>> > > >>> > > >>> > > >>> You should be able to just comment them out. I’ll prepare a proper fix. > > >>> > > >>> > > >>> > > >>> Cheers, > > >>> > > >>> Moritz > > >>> > > >>> > > >>> > > >>> On Tue, 14 Jul 2020 at 6:41 PM, Simon Peyton Jones via ghc-devs > > >>> <ghc-devs@haskell.org> wrote: > > >>> > > >>> I’m getting this failure in a clean HEAD build. Any ideas? I’m > > >>> totally stalled because I can’t build GHC any more. > > >>> > > >>> I’m using Windows Subsystem for Linux (WSL). > > >>> > > >>> Help help! > > >>> > > >>> Thanks > > >>> > > >>> Simon > > >>> > > >>> /home/simonpj/code/HEAD-9/rts/dist/build/libHSrts_thr_p.a(RtsSymbols.thr_p_o): > > >>> RtsSymbols.c:rtsSyms: error: undefined reference to '__stack_chk_guard' > > >>> > > >>> collect2: error: ld returned 1 exit status > > >>> > > >>> `cc' failed in phase `Linker'. (Exit code: 1) > > >>> > > >>> utils/iserv/ghc.mk:105: recipe for target > > >>> 'utils/iserv/stage2_p/build/tmp/ghc-iserv-prof' failed > > >>> > > >>> make[1]: *** [utils/iserv/stage2_p/build/tmp/ghc-iserv-prof] Error 1 > > >>> > > >>> make[1]: *** Waiting for unfinished jobs.... > > >>> > > >>> _______________________________________________ > > >>> ghc-devs mailing list > > >>> ghc-devs@haskell.org > > >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > >> > > >> _______________________________________________ > > >> ghc-devs mailing list > > >> ghc-devs@haskell.org > > >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > _______________________________________________ > > ghc-devs mailing list > > ghc-devs@haskell.org > > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > > -- > > Sergei _______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
