[RFC] Disable _FORTIFY_SOURCE
#5803
Comments
|
actually it does now, but its broken as hell :S in mingw_mac.h in the latest update you will find this -> #if _FORTIFY_SOURCE > 0 && __OPTIMIZE__ > 0 && __MINGW_GNUC_PREREQ(4, 1)
# if _FORTIFY_SOURCE > 1
# define __MINGW_FORTIFY_LEVEL 2
# else
# define __MINGW_FORTIFY_LEVEL 1
# endif
#else
# define __MINGW_FORTIFY_LEVEL 0
#endifif you do a search in the headers for __MINGW_FORTIFY_LEVEL Unfortunatly these dont seem to work correctly at the moment and you will get errors about undefined __chk functions in some sources if you remove the -D_FORTIFY_SOURCE flag. instead set it to -D_FORTIFY_SOURCE=0 to force it off. |
|
Yeah it seems these are SSP redirects so it gets a bit hairy. unfortunatly setting -D_FORTIFY_SOURCE=0 is also not enough i discovered, it still complains about __chk_fail being undefined :/ so the macro seems to be broken somehow. |
|
Urgh wait a sec, i know why it fails... previous packages have all been built with -D_FORTIFY_SOURCE=2 and the flag was propagated to the config files for several libraries. So it seems we will have to rebuild an unknown amount of packages with -D_FORTIFY_SOURCE=0 so that the compiler will not pick up this setting from some other library config. |
|
would building the crt against libssp with -fstack-protector-all be a workaround or would the redirects still require libssp to be linked in externally ?. If it works it would unfortunatly make builds require yet another dll (libssp-0.dll) unless we linked in the static version. Not sure if the libssp functions would at all be added to the crt libraries though seing that the redirects are mere macros for picking up libssp functions, and not real imports. |
|
Before building libssp the CRT has to exist, so I don't think it is in principle correct to have the CRT link against libssp. |
|
Aye it would be a nasty workaround, would probably be better to just incorporate the ssp code in the crt. Just throwing around some ideas atm. |
|
That could also bring licensing issues. Also if libssp code ever changes how should we synchronize with the upstream? |
ghost
mentioned this issue
|
Let's see how everything goes for some moments. New packages should now be built without this option. Perhaps we will want to enable this in the future (it can't be enabled when building GCC but may be enable-able for others). |
|
Neither if building the crt it would seem. After rebuilding the affected packages without _FORTIFY_SOURCE i had no problems atleast. |
|
btw. the -fstack-protector* flags should autoinclude libssp so there should be no need to force linking to libssp with LIBS+=" -lssp". If it does not then there are other problems upstream. |
|
Yes this thing should be only be enabled conditionally - mostly, but at least not always. If ppl want to enable this thing they had better add it themselves. |
|
gdb-git can't be built due to following errors: |
|
Seems it is defined in gdb/common/common-defs.h: /* Some distros enable _FORTIFY_SOURCE by default, which on occasion
has caused build failures with -Wunused-result when a patch is
developed on a distro that does not enable _FORTIFY_SOURCE. We
enable it here in order to try to catch these problems earlier;
plus this seems like a reasonable safety measure. The check for
optimization is required because _FORTIFY_SOURCE only works when
optimization is enabled. If _FORTIFY_SOURCE is already defined,
then we don't do anything. */
#if !defined _FORTIFY_SOURCE && defined __OPTIMIZE__ && __OPTIMIZE__ > 0
#define _FORTIFY_SOURCE 2
#endif |
|
New PR: msys2/MINGW-packages-dev#6 |
msys2 just dropped _FORTIFY_SOURCE support. See msys2/MINGW-packages#5803 Try to actually link it.
msys2 just dropped _FORTIFY_SOURCE support. See msys2/MINGW-packages#5803 Try to actually link it.
msys2 just dropped _FORTIFY_SOURCE support. See msys2/MINGW-packages#5803 Try to actually link it.
msys2 just dropped _FORTIFY_SOURCE support. See msys2/MINGW-packages#5803 Try to actually link it.
msys2 just dropped _FORTIFY_SOURCE support. See msys2/MINGW-packages#5803 Try to actually link it.
msys2 just dropped _FORTIFY_SOURCE support. See msys2/MINGW-packages#5803 Try to actually link it.
msys2 just dropped _FORTIFY_SOURCE support. See msys2/MINGW-packages#5803 Try to actually link it.
msys2 just dropped _FORTIFY_SOURCE support. See msys2/MINGW-packages#5803 Try to actually link it.
msys2 just dropped _FORTIFY_SOURCE support. See msys2/MINGW-packages#5803 Try to actually link it.
Enable -fstack-protector* on msys to get -lssp implicitly. mingw64 doesn't provide fortified functions which are required if you define FORTIFY_SOURCES to be > 0. By enabling -fstack-protector* you implicitly link against libssp which provides fortified variants of the missing functions. See: msys2/MINGW-packages#5803
Enable -fstack-protector* on msys to get -lssp implicitly. mingw64 doesn't provide fortified functions which are required if you define FORTIFY_SOURCES to be > 0. By enabling -fstack-protector* you implicitly link against libssp which provides fortified variants of the missing functions. See: msys2/MINGW-packages#5803
Enable -fstack-protector* on msys to get -lssp implicitly. mingw64 doesn't provide fortified functions which are required if you define FORTIFY_SOURCES to be > 0. By enabling -fstack-protector* you implicitly link against libssp which provides fortified variants of the missing functions. See: msys2/MINGW-packages#5803
|
One more thing, what is output of your |
|
standard mingw64 the TDM version pretty similar though i use a bit older version for the TDM compiler the lack of --with-boot-ldflags=-static-libstdc++ --with-stage1-ldflags=-static-libstdc++ is because the TDM version links to the static runtimes by default. ill try doing as you suggested. |
|
turns out the stpcpy symbol is from libgnu.a |
This file isn't preprocessed source, this is an object file. You would have needed to replace the Where is the source to this libgnu? |
|
Oh, also, when preprocessing the input files, add |
|
With those clues, I did find a discussion from 2014 about this same issue in a different form: https://lists.gnu.org/archive/html/emacs-devel/2014-12/msg02154.html In short, the issue is the following:
So even if mingw-w64 itself doesn't provide So if we want to practically paper over this, I guess we'll need to just bite the bullet and provide @mmuetzel When you test built it, did you build it with GCC or Clang? @revelator is building it with GCC for i686, in case that changes some factors in GCC's decisions about optimizing. |
I'm not very fond of doing workarounds in mingw-w64 for downstream issues (IMO they should have handled the fallback differently) but if there is no other way...
I have built it with i686 GCC 12.2 (the one provided by MSYS2) in MINGW32 subsystem but without changing configuration. If I manually modify |
|
ah yeah i added the -E but did not replace the -c so thats why it looked different than what i expected. |
|
actually i built it with both the i686 and x86_64 versions same bug with both so rather consistent on my end. |
|
sorry if it became a bit more of a goosechase been years since i last did some serious coding so im rather rusty. |
I built these packages in the MINGW64 environment using |
That shouldn't be necessary, as @mati865 reproduced the issue already - see above. Thanks anyway! |
|
I've created #13544 for the celt issue, not sure if that is the same cause or not. |
Thanks, that looks like an entirely different issue. Apparently the fortify macro/functions in mingw headers are incompatible with ... something .. in the way that project builds things. |
|
aye that is the same error i saw in celt so seems likely. |
|
I sent a patch to mingw-w64 now for implementing I also did manage to reproduce the hypothesis about how this happens, with a minimal example: char *strcpy(char *_Dest, const char *_Source);
char *stpcpy(char *_Dest, const char *_Source);
unsigned long long strlen(const char *_Str);
#ifdef _FORTIFY_SOURCE
extern __inline__ __attribute__((__always_inline__, __gnu_inline__)) __attribute__((__artificial__))
char *strcpy(char *__dst, const char *__src) {
return __builtin___strcpy_chk(__dst, __src, __builtin_object_size(__dst, 1));
}
#endif
int func(const char* src) {
char name[1000];
strcpy(name, src);
return strlen(name);
}$ x86_64-w64-mingw32-gcc opt-strcpy.c -S -o - -O2
[...]
func:
pushq %rbx
.seh_pushreg %rbx
subq $1040, %rsp
.seh_stackalloc 1040
.seh_endprologue
leaq 32(%rsp), %rbx
movq %rcx, %rdx
movq %rbx, %rcx
call stpcpy
subq %rbx, %rax
addq $1040, %rsp
popq %rbx
ret
[...]As long as the declaration of If we enable the fortification wrapper: $ x86_64-w64-mingw32-gcc opt-strcpy.c -S -o - -O2 -D_FORTIFY_SOURCE=2
[...]
func:
pushq %rbx
.seh_pushreg %rbx
subq $1040, %rsp
.seh_stackalloc 1040
.seh_endprologue
movl $1000, %r8d
leaq 32(%rsp), %rbx
movq %rcx, %rdx
movq %rbx, %rcx
call __stpcpy_chk
subq %rbx, %rax
addq $1040, %rsp
popq %rbx
ret
[...]Here, because GCC knows |
thanks, I've added it as a test to our test suite: msys2/msys2-tests#13
I've reduced it to one line now: #13544 (comment) |
Initially, it may seem like this function might not be needed in any form, since mingw-w64 lacks the main stpcpy function. However, third party projects may contain their own implementation of the stpcpy function. When GCC sees a declaration of the stpcpy function, it assumes that it is legal to do optimizations on strcpy+strlen into stpcpy. When strcpy is wrapped with fortification wrappers, so that strcpy ends up calling __builtin___strcpy_chk (which then calls __strcpy_chk), GCC can also transform this into __builtin___stpcpy_chk, which can generate a call to __stpcpy_chk. GCC's libssp does provide an implementation of __stpcpy_chk, even if the platform itself lacks stpcpy. Therefore, mingw-w64-crt's implementation of the ssp routines also does need an implementation of __stpcpy_chk, even if it is hard to practically produce calls to it. This should fix one issue discussed at msys2/MINGW-packages#5803 (comment). Signed-off-by: Martin Storsjö <martin@martin.st>
|
speex also affected by #13544 |
|
after the fix applied to the crt for the stcpy function it now builds emacs all the way to this -> then it fails... |
|
btw maybe a silly question but does the -fstack-protector flag still work after removing libssp ?. |
yes, see mingw-w64/mingw-w64@10394c9 |
|
ah you added it as part of the stpcpy fix ok then :) |
|
atm only two packages give me grief emacs and vala-language-server, emacs does not seem to be able to build the documentation anymore and vala-language-server gives me a rather weird error -> |
This follows https://sourceforge.net/p/mingw-w64/mailman/message/36764708/ which I think there is no solution other than disabling
-D_FORTIFY_SOURCE.Rationale:
-lssp(or-fstack-protectorwhich adds-lsspimplicitly) to work.-lsspmust be added intoLIBSexplicitly.The text was updated successfully, but these errors were encountered: