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:
https://gcc.gnu.org/onlinedocs/gcc/Inline.html
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
always compare.
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
detail:
--- a/newlib/libc/include/ssp/ssp.h
+++ b/newlib/libc/include/ssp/ssp.h
@@ -51,7 +51,6 @@
__chk_fail()
#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) \