On Sunday 13 July 2025 21:56:16 LIU Hao wrote:
> z
> 在 2025-7-13 21:43, Pali Rohár 写道:
> > On Sunday 13 July 2025 21:35:23 LIU Hao wrote:
> > > 在 2025-7-13 21:25, Pali Rohár 写道:
> > > > And throws warning: ‘no_stack_protector’ attribute directive ignored
> > > > [-Wattributes]
> > > >
> > > >
> > > > If I understand correctly the code at 3d-4c is the stack protection
> > > > check, which should have been disabled for that function. But because
> > > > the ___stack_chk_guard is being changed in the function, it cause
> > > > calling the ___stack_chk_fail.
> > > >
> > > > So the warning is NOT harmless and cannot be ignored. It is a real
> > > > issue.
> > >
> > > The CRT should not be built with stack protector.
> >
> > Ok. But the attribute __no_stack_protector__ is there to allow building
> > CRT with -fstack-protector, no?
>
> Yes; but it's not a very common use, and it requires GCC 11+.
>
>
> > But it is different than without the -fstack-protector-all flag.
> >
> > It is usable? If yes then I would propose to to define
> > __no_stack_protector__ as __optimize__("no-stack-protector") for those
> > older gcc.
>
> GCC doc says
> (https://gcc.gnu.org/onlinedocs/gcc/Common-Function-Attributes.html):
>
> optimize (level, …)
> optimize (string, …)
>
> ... Other substrings are taken as suffixes to the -f prefix jointly
> forming the
> name of an optimization option. See Options That Control Optimization.
>
> ...
>
> Not every optimization option that starts with the -f prefix specified by
> the
> attribute necessarily has an effect on the function. The optimize attribute
> should be used for debugging purposes only. It is not suitable in
> production code.
>
>
> AFAICT `-fstack-protector` is not an optimization option. And in addition to
> that, the last sentence looks like a big warning that it shouldn't be used
> here.
I see. But I think it is better to apply at least this "debugging
purposes" attribute than nothing. It is only for older gcc versions.
And with __SSP__ checks it can be targeted just for
-fstack-protector-string CRT builds, which is what the original commit
is aiming.
What about something like this in the stack_chk_guard.c file?
#if !defined(__clang__) && defined(__GNUC__) && __GNUC__ < 11
#if (defined(__SSP__) || defined(__SSP_STRONG__) || defined(__SSP_ALL__))
#define __no_stack_protector__ __optimize__("no-stack-protector")
#else
#define __no_stack_protector__
#endif
#endif
With new gcc / clang it does nothing, for older gcc without
-fstack-protector in CFLAGS it mutes the warning and for older gcc with
-fstack-protector in CFLAGS it workaround compilation of
stack_chk_guard.c file.
_______________________________________________
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
