* [ANNOUNCEMENT] TEST RELEASE: Cygwin 2.10.0-0.1
@ 2018-01-16 16:59 Corinna Vinschen
2018-01-17 10:42 ` Houder
2018-01-17 22:29 ` Ken Brown
0 siblings, 2 replies; 15+ messages in thread
From: Corinna Vinschen @ 2018-01-16 16:59 UTC (permalink / raw)
To: cygwin
Hi folks,
I uploaded a new Cygwin test release 2.10.0-0.1
I'm planning for a release end of January. Please test.
=======================================================================
What's new:
-----------
- New open(2) flags O_TMPFILE and O_NOATIME.
- scanf/wscanf now handle the POSIX %m modifier.
- scanf now handles the %l[ conversion.
- New APIs: sigtimedwait, wmempcpy.
Bug Fixes
---------
- Fix a problem in unlink on NFS.
Addresses: Shows up in GAWK testsuite test "testext"
- Fix errno setting bug in posix_fadvise and posix_fallocate.
Addresses: https://cygwin.com/ml/cygwin-patches/2017-q4/msg00026.html
- Fix two bugs in the limit of large numbers of sockets.
Addresses: https://cygwin.com/ml/cygwin/2017-11/msg00052.html
- Fix a fork failure with private anonymous mmaps.
Addresses: https://cygwin.com/ml/cygwin/2017-12/msg00061.html
- Remove a call to fflush from ftell{o}, which may result in wrong offsets.
Addresses: https://cygwin.com/ml/cygwin/2017-12/msg00151.html
- Fix file pointer computation after short writes on block devices.
Addresses: https://cygwin.com/ml/cygwin/2017-12/msg00151.html
=======================================================================
Have fun,
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat
--
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
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 2.10.0-0.1
2018-01-16 16:59 [ANNOUNCEMENT] TEST RELEASE: Cygwin 2.10.0-0.1 Corinna Vinschen
@ 2018-01-17 10:42 ` Houder
2018-01-17 10:50 ` Corinna Vinschen
2018-01-17 22:29 ` Ken Brown
1 sibling, 1 reply; 15+ messages in thread
From: Houder @ 2018-01-17 10:42 UTC (permalink / raw)
To: cygwin
On Tue, 16 Jan 2018 16:51:08, Corinna Vinschen wrote:
> Hi folks,
>
>
> I uploaded a new Cygwin test release 2.10.0-0.1
.. did you really upload it? As the mirror tells me it is not there ...
Henri
--
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
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 2.10.0-0.1
2018-01-17 10:42 ` Houder
@ 2018-01-17 10:50 ` Corinna Vinschen
2018-01-17 11:40 ` Houder
0 siblings, 1 reply; 15+ messages in thread
From: Corinna Vinschen @ 2018-01-17 10:50 UTC (permalink / raw)
To: cygwin
[-- Attachment #1: Type: text/plain, Size: 539 bytes --]
On Jan 17 11:42, Houder wrote:
> On Tue, 16 Jan 2018 16:51:08, Corinna Vinschen wrote:
> > Hi folks,
> >
> >
> > I uploaded a new Cygwin test release 2.10.0-0.1
>
> .. did you really upload it? As the mirror tells me it is not there ...
Thanks for the heads up. I only uploaded the 32 bit version,
accidentally. The 64 bit version will be up in a bit, sorry.
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 2.10.0-0.1
2018-01-17 10:50 ` Corinna Vinschen
@ 2018-01-17 11:40 ` Houder
2018-01-17 12:07 ` Houder
0 siblings, 1 reply; 15+ messages in thread
From: Houder @ 2018-01-17 11:40 UTC (permalink / raw)
To: cygwin
On Wed, 17 Jan 2018 11:50:23, Corinna Vinschen wrote:
> --+nBD6E3TurpgldQp
> Content-Type: text/plain; charset=utf-8
> Content-Disposition: inline
> Content-Transfer-Encoding: quoted-printable
>
> On Jan 17 11:42, Houder wrote:
> > On Tue, 16 Jan 2018 16:51:08, Corinna Vinschen wrote:
> > > Hi folks,
> > >=20
> > >=20
> > > I uploaded a new Cygwin test release 2.10.0-0.1
> >=20
> > .. did you really upload it? As the mirror tells me it is not there ...
>
> Thanks for the heads up. I only uploaded the 32 bit version,
> accidentally. The 64 bit version will be up in a bit, sorry.
You are right. It has arrived already! (Twente mirror, the Netherlands)
Thanks, Henri
--
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
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 2.10.0-0.1
2018-01-17 11:40 ` Houder
@ 2018-01-17 12:07 ` Houder
0 siblings, 0 replies; 15+ messages in thread
From: Houder @ 2018-01-17 12:07 UTC (permalink / raw)
To: cygwin
On Wed, 17 Jan 2018 12:40:26, Houder wrote:
> On Wed, 17 Jan 2018 11:50:23, Corinna Vinschen wrote:
> > --+nBD6E3TurpgldQp
> > Content-Type: text/plain; charset=utf-8
> > Content-Disposition: inline
> > Content-Transfer-Encoding: quoted-printable
> >
> > On Jan 17 11:42, Houder wrote:
> > > On Tue, 16 Jan 2018 16:51:08, Corinna Vinschen wrote:
> > > > Hi folks,
> > > >=20
> > > >=20
> > > > I uploaded a new Cygwin test release 2.10.0-0.1
> > >=20
> > > .. did you really upload it? As the mirror tells me it is not there ...
> >
> > Thanks for the heads up. I only uploaded the 32 bit version,
> > accidentally. The 64 bit version will be up in a bit, sorry.
>
> You are right. It has arrived already! (Twente mirror, the Netherlands)
... although setup.ini still? has to be updated ...
Henri
--
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
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 2.10.0-0.1
2018-01-16 16:59 [ANNOUNCEMENT] TEST RELEASE: Cygwin 2.10.0-0.1 Corinna Vinschen
2018-01-17 10:42 ` Houder
@ 2018-01-17 22:29 ` Ken Brown
2018-01-18 14:36 ` Ken Brown
1 sibling, 1 reply; 15+ messages in thread
From: Ken Brown @ 2018-01-17 22:29 UTC (permalink / raw)
To: cygwin
On 1/16/2018 10:51 AM, Corinna Vinschen wrote:
> Hi folks,
>
>
> I uploaded a new Cygwin test release 2.10.0-0.1
>
> I'm planning for a release end of January. Please test.
Do we need a new gcc release to go along with the recent ssp changes?
STC:
$ cat ssp_test.c
#define _FORTIFY_SOURCE 1
#include <unistd.h>
$ gcc -O1 -c ssp_test.c
In file included from /usr/include/sys/unistd.h:592:0,
from /usr/include/unistd.h:4,
from ssp_test.c:2:
/usr/lib/gcc/x86_64-pc-cygwin/6.4.0/include/ssp/unistd.h:38:17: fatal
error: ssp.h: No such file or directory
#include <ssp.h>
^
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
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 2.10.0-0.1
2018-01-17 22:29 ` Ken Brown
@ 2018-01-18 14:36 ` Ken Brown
2018-01-18 21:30 ` Yaakov Selkowitz
0 siblings, 1 reply; 15+ messages in thread
From: Ken Brown @ 2018-01-18 14:36 UTC (permalink / raw)
To: cygwin
On 1/17/2018 5:29 PM, Ken Brown wrote:
> On 1/16/2018 10:51 AM, Corinna Vinschen wrote:
>> Hi folks,
>>
>>
>> I uploaded a new Cygwin test release 2.10.0-0.1
>>
>> I'm planning for a release end of January. Please test.
>
> Do we need a new gcc release to go along with the recent ssp changes?
The following commit message seems to answer my question:
commit 3e8fc7d9f21329d5a98ec3cf6de138bce9bc2c05
Author: Yaakov Selkowitz <yselkowi@redhat.com>
Date: Mon Nov 27 23:07:10 2017 -0600
ssp: add Object Size Checking common code
[...]
Note that this does require building gcc with --disable-libssp and
gcc_cv_libc_provides_ssp=yes.
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?
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
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 2.10.0-0.1
2018-01-18 14:36 ` Ken Brown
@ 2018-01-18 21:30 ` Yaakov Selkowitz
2018-01-18 23:28 ` Ken Brown
0 siblings, 1 reply; 15+ messages in thread
From: Yaakov Selkowitz @ 2018-01-18 21:30 UTC (permalink / raw)
To: cygwin
[-- Attachment #1.1: Type: text/plain, Size: 869 bytes --]
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. 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.
--
Yaakov
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 2.10.0-0.1
2018-01-18 21:30 ` Yaakov Selkowitz
@ 2018-01-18 23:28 ` Ken Brown
2018-01-20 3:27 ` Ken Brown
0 siblings, 1 reply; 15+ messages in thread
From: Ken Brown @ 2018-01-18 23:28 UTC (permalink / raw)
To: cygwin
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.
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
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 2.10.0-0.1
2018-01-18 23:28 ` Ken Brown
@ 2018-01-20 3:27 ` Ken Brown
2018-01-20 12:23 ` Ken Brown
0 siblings, 1 reply; 15+ messages in thread
From: Ken Brown @ 2018-01-20 3:27 UTC (permalink / raw)
To: cygwin
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.
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
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 2.10.0-0.1
2018-01-20 3:27 ` Ken Brown
@ 2018-01-20 12:23 ` Ken Brown
2018-01-20 23:49 ` Ken Brown
0 siblings, 1 reply; 15+ messages in thread
From: Ken Brown @ 2018-01-20 12:23 UTC (permalink / raw)
To: cygwin
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
[...]
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
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 2.10.0-0.1
2018-01-20 12:23 ` Ken Brown
@ 2018-01-20 23:49 ` Ken Brown
2018-01-24 19:25 ` Ken Brown
0 siblings, 1 reply; 15+ messages in thread
From: Ken Brown @ 2018-01-20 23:49 UTC (permalink / raw)
To: cygwin
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
> [...]
And the problem is still there with the new GCC that was just released.
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
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 2.10.0-0.1
2018-01-20 23:49 ` Ken Brown
@ 2018-01-24 19:25 ` Ken Brown
2018-01-25 0:16 ` Yaakov Selkowitz
0 siblings, 1 reply; 15+ messages in thread
From: Ken Brown @ 2018-01-24 19:25 UTC (permalink / raw)
To: cygwin
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
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 2.10.0-0.1
2018-01-24 19:25 ` Ken Brown
@ 2018-01-25 0:16 ` Yaakov Selkowitz
2018-01-25 2:42 ` Ken Brown
0 siblings, 1 reply; 15+ messages in thread
From: Yaakov Selkowitz @ 2018-01-25 0:16 UTC (permalink / raw)
To: cygwin
[-- Attachment #1.1: Type: text/plain, Size: 2106 bytes --]
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) \
--
Yaakov
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 2.10.0-0.1
2018-01-25 0:16 ` Yaakov Selkowitz
@ 2018-01-25 2:42 ` Ken Brown
0 siblings, 0 replies; 15+ messages in thread
From: Ken Brown @ 2018-01-25 2:42 UTC (permalink / raw)
To: cygwin
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
^ permalink raw reply [flat|nested] 15+ messages in thread
end of thread, other threads:[~2018-01-25 2:42 UTC | newest]
Thread overview: 15+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-01-16 16:59 [ANNOUNCEMENT] TEST RELEASE: Cygwin 2.10.0-0.1 Corinna Vinschen
2018-01-17 10:42 ` Houder
2018-01-17 10:50 ` Corinna Vinschen
2018-01-17 11:40 ` Houder
2018-01-17 12:07 ` Houder
2018-01-17 22:29 ` Ken Brown
2018-01-18 14:36 ` Ken Brown
2018-01-18 21:30 ` Yaakov Selkowitz
2018-01-18 23:28 ` Ken Brown
2018-01-20 3:27 ` Ken Brown
2018-01-20 12:23 ` Ken Brown
2018-01-20 23:49 ` Ken Brown
2018-01-24 19:25 ` Ken Brown
2018-01-25 0:16 ` Yaakov Selkowitz
2018-01-25 2:42 ` Ken Brown
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).