This is the mail archive of the
cygwin
mailing list for the Cygwin project.
Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 2.10.0-0.1
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:
>>> On 1/18/2018 6:28 PM, Ken Brown wrote:
>>>> On 1/18/2018 4:30 PM, Yaakov Selkowitz wrote:
>>>>> On 2018-01-18 08:35, Ken Brown wrote:
>>>>>> On 1/17/2018 5:29 PM, Ken Brown wrote:
>>>>>>> Do we need a new gcc release to go along with the recent ssp
>>>>>>> changes?
>>>>>>
>>>>>> The following commit message seems to answer my question:
>>>>>>
>>>>>> Note that this does require building gcc with
>>>>>> --disable-libssp and
>>>>>> gcc_cv_libc_provides_ssp=yes.
>>>>>
>>>>> Correct.
>>>>>
>>>>>> Are there plans to coordinate the release of Cygwin 2.10.0 with a new
>>>>>> gcc release? In the meantime, I guess package maintainers have to
>>>>>> build
>>>>>> with -U_FORTIFY_SOURCE in order to test building with Cygwin
>>>>>> 2.10.0. Or
>>>>>> am I missing something?
>>>>>
>>>>> -D_FORTIFY_SOURCE is not the default, so simply omitting it is
>>>>> sufficient.
>>>>
>>>> I was talking about building projects in which _FORTIFY_SOURCE is
>>>> defined by default. That happens, for instance, in the gnulib
>>>> subdirectory of the emacs tree, so it may affect other projects that
>>>> use gnulib also.
>>>>
>>>>> You could also just delete
>>>>> /usr/lib/gcc/*-pc-cygwin/6.4.0/include/ssp, since we won't need it
>>>>> anymore and it wasn't even being used properly in the first place.
>>>>
>>>> That's a simpler workaround than what I was doing. Thanks.
>>>
>>> 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.
>>> [More precisely, the file uses an external function foo() with a
>>> parameter 'bar' that's a pointer to a function; foo is called in
>>> fileio.c with bar = 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 realize I haven't given you full details, but it might be a few
>>> days until I have a chance to extract an STC for this issue, so I
>>> thought I'd give it a shot.
>>>
>>> If you can't answer the question based on the information above, I'll
>>> make an STC as soon as I can.
>>
>> 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);
>> }
>>
>> $ gcc -c -O1 ssp_test.c
>>
>> $ objdump -x ssp_test.o | grep readlinkat
>> 6 .rdata$.refptr.__ssp_protected_readlinkat 00000010
>> 0000000000000000 0000000000000000 00000180 2**4
>> [...]
The following patch seems to fix the problem:
--- ssp.h~ 2018-01-22 09:18:18.000000000 -0500
+++ ssp.h 2018-01-24 13:44:55.856635800 -0500
@@ -41,7 +41,7 @@
#endif
#define __ssp_real(fun) __ssp_real_(fun)
-#define __ssp_inline extern __inline__ __attribute__((__always_inline__, __gnu_inline__))
+#define __ssp_inline extern __inline__ __attribute__((__always_inline__))
#define __ssp_bos(ptr) __builtin_object_size(ptr, __SSP_FORTIFY_LEVEL > 1)
#define __ssp_bos0(ptr) __builtin_object_size(ptr, 0)
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__.
Yaakov, is there a reason that Cygwin needs __gnu_inline__? It apparently
prevents fortified functions from being used as function pointers.
Using my test case again, here's what happens with and without __gnu_inline__:
With:
$ gcc -O1 -c ssp_test.c && objdump -x ssp_test.o | grep readlinkat
6 .rdata$.refptr.__ssp_protected_readlinkat 00000010 0000000000000000 0000000000000000 00000180 2**4
CONTENTS, ALLOC, LOAD, RELOC, READONLY, DATA, LINK_ONCE_DISCARD (COMDAT .refptr.__ssp_protected_readlinkat 18)
[ 4](sec 7)(fl 0x00)(ty 0)(scl 3) (nx 1) 0x0000000000000000 .rdata$.refptr.__ssp_protected_readlinkat
[ 18](sec 7)(fl 0x00)(ty 0)(scl 2) (nx 0) 0x0000000000000000 .refptr.__ssp_protected_readlinkat
[ 19](sec 0)(fl 0x00)(ty 0)(scl 2) (nx 0) 0x0000000000000000 __ssp_protected_readlinkat
0000000000000007 R_X86_64_PC32 __ssp_protected_readlinkat
RELOCATION RECORDS FOR [.rdata$.refptr.__ssp_protected_readlinkat]:
0000000000000000 R_X86_64_64 __ssp_protected_readlinkat
Without:
$ gcc -O1 -c ssp_test.c && objdump -x ssp_test.o | grep readlinkat
[ 2](sec 1)(fl 0x00)(ty 20)(scl 2) (nx 1) 0x0000000000000000 __ssp_protected_readlinkat
[ 27](sec 0)(fl 0x00)(ty 0)(scl 2) (nx 0) 0x0000000000000000 readlinkat
0000000000000005 R_X86_64_PC32 readlinkat
Ken
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple