X-Recipient: archive-cygwin AT delorie DOT com
DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:subject:to:references:from:message-id:date
	:mime-version:in-reply-to:content-type
	:content-transfer-encoding; q=dns; s=default; b=n8/KxFJeIabU6XCi
	bBAiwbNP4qh1q8UeL/FxoOcXQeeD+/lZO38P2XdZ0zJodag09oEOjvUsodQhqMcN
	9zNV+v10s2C2pyYoUi6xFp9Ft2UCjR53XtSZ4s5BFj+a5md7E4wAMx8H65ReoUGm
	w6qcVmR+c6w/hISu/mvQvl6vRXo=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:subject:to:references:from:message-id:date
	:mime-version:in-reply-to:content-type
	:content-transfer-encoding; s=default; bh=ukEGTYNQ6wIneDvhnZPAiP
	SGCDI=; b=IxSEc+9387vm1XdlU3pJKL1CVq6GbeSFBx+F/GQp197yij18+aXnFG
	A1zQOzKL0IGW8T5eO0/cuPQrr0ZHigN1sRnn/BkHnkQWNZ2lUURBZDnnRrJxrtHG
	XRj6+mzIG1wrBLeeIiQboo8o5BxmcuvpNz4GR60lcz2Fs4xJSpgOc=
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id: <cygwin.cygwin.com>
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com
Authentication-Results: sourceware.org; auth=none
X-Virus-Found: No
X-Spam-SWARE-Status: No, score=-10.8 required=5.0 tests=AWL,BAYES_00,GIT_PATCH_2,GIT_PATCH_3,KAM_NUMSUBJECT,KAM_SHORT,SPF_HELO_PASS,SPF_PASS,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 spammy=
X-HELO: limerock01.mail.cornell.edu
X-CornellRouted: This message has been Routed already.
Subject: Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 2.10.0-0.1
To: cygwin AT cygwin DOT com
References: <announce DOT 20180116155108 DOT GA9503 AT calimero DOT vinschen DOT de> <9990d909-f112-9658-1b0f-d63e3f338a18 AT cornell DOT edu> <4f7edc68-4c98-8fa3-9fef-47bdd3343330 AT cornell DOT edu> <3b738a06-a3b8-210b-2886-4c9701efcd48 AT cygwin DOT com> <eb4e6cf2-12aa-bb4c-738e-f2259f58f3fe AT cornell DOT edu> <c5a92ae1-3b63-0227-f170-fa1d0ac959eb AT cornell DOT edu> <39045e32-8a2c-c767-0fcd-27d544ba6d93 AT cornell DOT edu> <e8cdfc99-bcad-eb80-ec48-9e1bdefbe69d AT cornell DOT edu> <5769e163-8716-23b3-520e-dbae6faaa84a AT cornell DOT edu> <85d3c271-55c6-0002-42cd-f46ef588be4d AT cygwin DOT com>
From: Ken Brown <kbrown AT cornell DOT edu>
Message-ID: <901aaf73-6eb9-207a-e6e7-6b900f844e02@cornell.edu>
Date: Wed, 24 Jan 2018 21:42:38 -0500
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2
MIME-Version: 1.0
In-Reply-To: <85d3c271-55c6-0002-42cd-f46ef588be4d@cygwin.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
X-PMX-Cornell-Gauge: Gauge=XX
X-PMX-CORNELL-AUTH-RESULTS: dkim-out=none;
X-IsSubscribed: yes

On 1/24/2018 7:16 PM, Yaakov Selkowitz wrote:
> 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) \

Works for me.

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