[ANNOUNCEMENT] TEST RELEASE: Cygwin 2.10.0-0.1
Thu Jan 25 00:16:00 GMT 2018
On 2018-01-24 13:25, Ken Brown wrote:
> On 1/20/2018 6:49 PM, Ken Brown wrote:
>> On 1/20/2018 7:23 AM, Ken Brown wrote:
>>> On 1/19/2018 10:27 PM, Ken Brown wrote:
>>>> Here's another issue that's come up with _FORTIFY_SOURCE. One of the
>>>> emacs source files, fileio.c, makes use of a pointer to readlinkat.
>>>> When _FORTIFY_SOURCE > 0, this leads to an "undefined reference to
>>>> `__ssp_protected_readlinkat'" linking error. Does this sound like
>>>> something that will be fixed with the new gcc release?
>>> I got to this sooner than expected:
>>> $ cat ssp_test.c
>>> #define _FORTIFY_SOURCE 1
>>> #include <unistd.h>
>>> void foo (ssize_t (*preadlinkat) (int, char const *, char *, size_t));
>>> void baz ()
>>> foo (readlinkat);
> The following patch seems to fix the problem:
> -#define __ssp_inline extern __inline__ __attribute__((__always_inline__, __gnu_inline__))
> +#define __ssp_inline extern __inline__ __attribute__((__always_inline__))
No, that would have other consequences:
> I arrived at this by comparing Cygwin's ssp.h with NetBSD's, on which
> Cygwin's was based, and I noticed that NetBSD didn't use __gnu_inline__.
The BSDs also stuck with GCC 4.2 due to licensing reasons, so you can't
> Yaakov, is there a reason that Cygwin needs __gnu_inline__?
Because the semantics of inline changed in GCC 4.3.
> It apparently prevents fortified functions from being used as function pointers.
I am currently testing the following, which seems to match glibc in this
@@ -51,7 +51,6 @@
#define __ssp_decl(rtype, fun, args) \
rtype __ssp_real_(fun) args __asm__(__ASMNAME(#fun)); \
-__ssp_inline rtype fun args __asm__(__ASMNAME("__ssp_protected_" #fun)); \
__ssp_inline rtype fun args
#define __ssp_redirect_raw(rtype, fun, args, call, cond, bos) \
__ssp_decl(rtype, fun, args) \
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 228 bytes
Desc: OpenPGP digital signature
More information about the Cygwin