Standard shared libraries with executable stack


(Jongsu Kim) #1

I am testing Swift in "Windows Subsystem for Linux" which is a new feature
of Windows 10 Anniversary Update scheduled in this year. WSL is Ubuntu LTS
14.04 compatible in user space.

Swift runtime libraries such as libswiftCore.so are marked Executable
Stack, which have no problem in Linux.

dlopen()'ing swift runtime libraries causes mprotect() with PROT_GROWSDOWN,
which is not documented but verified with strace.

WSL has not implemented PROT_GROWSDOWN feature because of clean room
development.

Swift runtime libraries had not been marked Executable Stack before Febrary
snapshot. And cmark and llvm/clang shared libraries are not marked too.

***My request is swift runtime libraries be not marked Executable Stack.***

Thanks in advance.

Kim, Jongsu


(Dmitri Gribenko) #2

Hi,

This could have been caused by our switch from the BFD linker to gold.
Could you try linking a hello world program using gold linker and
running it in WSL?

Are you sure that PROT_GROWSDOWN is the flag that enables executable
stack? I thought that's what PROT_EXEC is for. I'm not sure what
PROT_GROWSDOWN actually changes, if I were to speculate, I'd say it
could be a marker that means "this is a stack" or maybe even be just a
performance hint.

Dmitri

···

On Sat, Jun 11, 2016 at 8:12 AM, 김종수 via swift-dev <swift-dev@swift.org> wrote:

I am testing Swift in "Windows Subsystem for Linux" which is a new feature
of Windows 10 Anniversary Update scheduled in this year. WSL is Ubuntu LTS
14.04 compatible in user space.

Swift runtime libraries such as libswiftCore.so are marked Executable Stack,
which have no problem in Linux.

dlopen()'ing swift runtime libraries causes mprotect() with PROT_GROWSDOWN,
which is not documented but verified with strace.

WSL has not implemented PROT_GROWSDOWN feature because of clean room
development.

Swift runtime libraries had not been marked Executable Stack before Febrary
snapshot. And cmark and llvm/clang shared libraries are not marked too.

***My request is swift runtime libraries be not marked Executable Stack.***

--
main(i,j){for(i=2;;i++){for(j=2;j<i;j++){if(!(i%j)){j=0;break;}}if
(j){printf("%d\n",i);}}} /*Dmitri Gribenko <gribozavr@gmail.com>*/


(Ryan Lovelett) #3

> I am testing Swift in "Windows Subsystem for Linux" which is a new feature
> of Windows 10 Anniversary Update scheduled in this year. WSL is Ubuntu LTS
> 14.04 compatible in user space.
>
> Swift runtime libraries such as libswiftCore.so are marked Executable Stack,
> which have no problem in Linux.
>
> dlopen()'ing swift runtime libraries causes mprotect() with PROT_GROWSDOWN,
> which is not documented but verified with strace.
>
> WSL has not implemented PROT_GROWSDOWN feature because of clean room
> development.
>
> Swift runtime libraries had not been marked Executable Stack before Febrary
> snapshot. And cmark and llvm/clang shared libraries are not marked too.
>
> ***My request is swift runtime libraries be not marked Executable Stack.***

Hi,

This could have been caused by our switch from the BFD linker to gold.
Could you try linking a hello world program using gold linker and
running it in WSL?

I _think_ this problem existed before the switch from BFD to gold.

I build and package a version of Swift for Linux. During the package
processes makepkg [1] checks the installed binaries for common gotchas
(I tried looking up exactly what is run but could not find it quickly).

My point is that I've been seeing:

swiftc W: ELF file ('usr/bin/swift-test') has executable stack.
swiftc W: ELF file ('usr/bin/repl_swift') has executable stack.
swiftc W: ELF file ('usr/bin/swift-build') has executable stack.
swiftc W: ELF file ('usr/lib/swift/pm/libPackageDescription.so') has
executable stack.
swiftc W: ELF file ('usr/lib/swift/linux/libswiftGlibc.so') has
executable stack.
swiftc W: ELF file ('usr/lib/swift/linux/libXCTest.so') has executable
stack.
swiftc W: ELF file ('usr/lib/swift/linux/libswiftCore.so') has
executable stack.
swiftc W: ELF file ('usr/lib/swift/linux/libFoundation.so') has
executable stack.

Since at least the 20160208a release, but probably longer, I have been
seeing the above errors. That predates the BFD to gold switch by at
least a month. Though I do admit I don't remember the exact date that
change landed.

I have all the build logs dating back to February 22nd if that helps in
anyway. Just food for thought.

[1] https://www.archlinux.org/pacman/makepkg.8.html

···

On Mon, Jun 13, 2016, at 11:33 PM, Dmitri Gribenko via swift-dev wrote:

On Sat, Jun 11, 2016 at 8:12 AM, 김종수 via swift-dev <swift-dev@swift.org> > wrote:

Are you sure that PROT_GROWSDOWN is the flag that enables executable
stack? I thought that's what PROT_EXEC is for. I'm not sure what
PROT_GROWSDOWN actually changes, if I were to speculate, I'd say it
could be a marker that means "this is a stack" or maybe even be just a
performance hint.

Dmitri

--
main(i,j){for(i=2;;i++){for(j=2;j<i;j++){if(!(i%j)){j=0;break;}}if
(j){printf("%d\n",i);}}} /*Dmitri Gribenko <gribozavr@gmail.com>*/
_______________________________________________
swift-dev mailing list
swift-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-dev


(Jongsu Kim) #4

Hi,

This could have been caused by our switch from the BFD linker to gold.

Could you try linking a hello world program using gold linker and
running it in WSL?

I tried to build Swift by not using -fuse-gold option and the result was
same.

Are you sure that PROT_GROWSDOWN is the flag that enables executable

stack? I thought that's what PROT_EXEC is for. I'm not sure what
PROT_GROWSDOWN actually changes, if I were to speculate, I'd say it
could be a marker that means "this is a stack" or maybe even be just a
performance hint.

You are right. The executable stack is enabled by PROT_EXEC.

But Swift shared library's executable stack seems to set PROT_EXEC AND
PROT_GROWSDOWN according to strace.

I don't know what causes Swift shared library to have executable stack
since Febrary 25 snapshot. Febrary 8 snapshot and Swift 2.X branches have
no such executable stack shared library.

Thanks,

-Kim, Jongsu


(Han Sang-jin) #5

Hi, Kim.

I have the WSL on Windows Preview.

Could you show the test source/command ?

-Han Sangjin

:

···

2016-06-14 21:10 GMT+09:00 Ryan Lovelett via swift-dev <swift-dev@swift.org>

On Mon, Jun 13, 2016, at 11:33 PM, Dmitri Gribenko via swift-dev wrote:
> On Sat, Jun 11, 2016 at 8:12 AM, 김종수 via swift-dev <swift-dev@swift.org> > > wrote:
> > I am testing Swift in "Windows Subsystem for Linux" which is a new
feature
> > of Windows 10 Anniversary Update scheduled in this year. WSL is Ubuntu
LTS
> > 14.04 compatible in user space.
> >
> > Swift runtime libraries such as libswiftCore.so are marked Executable
Stack,
> > which have no problem in Linux.
> >
> > dlopen()'ing swift runtime libraries causes mprotect() with
PROT_GROWSDOWN,
> > which is not documented but verified with strace.
> >
> > WSL has not implemented PROT_GROWSDOWN feature because of clean room
> > development.
> >
> > Swift runtime libraries had not been marked Executable Stack before
Febrary
> > snapshot. And cmark and llvm/clang shared libraries are not marked too.
> >
> > ***My request is swift runtime libraries be not marked Executable
Stack.***
>
> Hi,
>
> This could have been caused by our switch from the BFD linker to gold.
> Could you try linking a hello world program using gold linker and
> running it in WSL?

I _think_ this problem existed before the switch from BFD to gold.

I build and package a version of Swift for Linux. During the package
processes makepkg [1] checks the installed binaries for common gotchas
(I tried looking up exactly what is run but could not find it quickly).

My point is that I've been seeing:

swiftc W: ELF file ('usr/bin/swift-test') has executable stack.
swiftc W: ELF file ('usr/bin/repl_swift') has executable stack.
swiftc W: ELF file ('usr/bin/swift-build') has executable stack.
swiftc W: ELF file ('usr/lib/swift/pm/libPackageDescription.so') has
executable stack.
swiftc W: ELF file ('usr/lib/swift/linux/libswiftGlibc.so') has
executable stack.
swiftc W: ELF file ('usr/lib/swift/linux/libXCTest.so') has executable
stack.
swiftc W: ELF file ('usr/lib/swift/linux/libswiftCore.so') has
executable stack.
swiftc W: ELF file ('usr/lib/swift/linux/libFoundation.so') has
executable stack.

Since at least the 20160208a release, but probably longer, I have been
seeing the above errors. That predates the BFD to gold switch by at
least a month. Though I do admit I don't remember the exact date that
change landed.

I have all the build logs dating back to February 22nd if that helps in
anyway. Just food for thought.

[1] https://www.archlinux.org/pacman/makepkg.8.html

>
> Are you sure that PROT_GROWSDOWN is the flag that enables executable
> stack? I thought that's what PROT_EXEC is for. I'm not sure what
> PROT_GROWSDOWN actually changes, if I were to speculate, I'd say it
> could be a marker that means "this is a stack" or maybe even be just a
> performance hint.
>
> Dmitri
>
> --
> main(i,j){for(i=2;;i++){for(j=2;j<i;j++){if(!(i%j)){j=0;break;}}if
> (j){printf("%d\n",i);}}} /*Dmitri Gribenko <gribozavr@gmail.com>*/
> _______________________________________________
> swift-dev mailing list
> swift-dev@swift.org
> https://lists.swift.org/mailman/listinfo/swift-dev
_______________________________________________
swift-dev mailing list
swift-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-dev


(Dmitri Gribenko) #6

'-fuse-gold' is implicitly the default now. We have switched to the
gold linker because the BFD linker had bugs and could not link Swift
libraries at all.

Dmitri

···

On Thu, Jun 16, 2016 at 5:17 AM, Jongsu Kim <kimjs29@gmail.com> wrote:

Hi,

This could have been caused by our switch from the BFD linker to gold.
Could you try linking a hello world program using gold linker and
running it in WSL?

I tried to build Swift by not using -fuse-gold option and the result was
same.

--
main(i,j){for(i=2;;i++){for(j=2;j<i;j++){if(!(i%j)){j=0;break;}}if
(j){printf("%d\n",i);}}} /*Dmitri Gribenko <gribozavr@gmail.com>*/


(Han Sang-jin) #7

Hi, Kim.

The test result is same on WSL build 14342.

There is similar report in
https://github.com/Microsoft/BashOnWindows/issues/286 .
MS engineer recognized this and replied that give them feedback on the
uservoice for prioritizing, currently it has only 3 votes.

-Han Sangjin

···

2016-06-16 21:17 GMT+09:00 Jongsu Kim via swift-dev <swift-dev@swift.org>:

Hi,

This could have been caused by our switch from the BFD linker to gold.

Could you try linking a hello world program using gold linker and
running it in WSL?

I tried to build Swift by not using -fuse-gold option and the result was
same.

Are you sure that PROT_GROWSDOWN is the flag that enables executable

stack? I thought that's what PROT_EXEC is for. I'm not sure what
PROT_GROWSDOWN actually changes, if I were to speculate, I'd say it
could be a marker that means "this is a stack" or maybe even be just a
performance hint.

You are right. The executable stack is enabled by PROT_EXEC.

But Swift shared library's executable stack seems to set PROT_EXEC AND
PROT_GROWSDOWN according to strace.

I don't know what causes Swift shared library to have executable stack
since Febrary 25 snapshot. Febrary 8 snapshot and Swift 2.X branches have
no such executable stack shared library.

Thanks,

-Kim, Jongsu

_______________________________________________
swift-dev mailing list
swift-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-dev


(Jongsu Kim) #8

Hi, Han

The test code is as follows:

#include <stdio.h>
#include <dlfcn.h>

int main()
{
    if
(!dlopen("swift-3.0-preview-1-ubuntu14.04/usr/lib/swift/linux/libswiftCore.so",
RTLD_LAZY | RTLD_GLOBAL))
        fprintf(stderr, "%s\n", dlerror());
}

The executable stack flag is queried as follows:

sudo execstack -q
swift-3.0-preview-1-ubuntu14.04/usr/lib/swift/linux/libswiftCore.so

If the executable stack flag is set, the stderr output is as follows:

swift-3.0-preview-1-ubuntu14.04/usr/lib/swift/linux/libswiftCore.so: cannot
enable executable stack as shared object requires: Invalid argument

And strace ouput tail is as follows:

mprotect(0x7ffffe5c3000, 4096,
PROT_READ|PROT_WRITE|PROT_EXEC|PROT_GROWSDOWN) = -1 EINVAL (Invalid
argument)
close(3) = 0
write(2, "swift-3.0-preview-1-ubuntu14.04/"...,
144swift-3.0-preview-1-ubuntu14.04/usr/lib/swift/linux/libswiftCore.so:
cannot enable executable stack as shared object requires: Invalid argument)
= 144
exit_group(144) = ?
+++ exited with 144 +++

If the executable stack flag is cleared by using execstack -c option, there
is no error.

Of course on Ubuntu 14.04 there is no error with the executable stack flag
on.

To clarify my request, I don't know how the Swift shared libraries'
executable stack flag has been set since Febrary 25 snapshot because
Febrary 8 snapshot and Swift 2.X branches have no such executable stack
shared libraries.

I tested on WSL Build 14366.

Thanks.

···

On Wed, Jun 15, 2016 at 9:48 AM, Sangjin Han <tinysun.net@gmail.com> wrote:

Hi, Kim.

I have the WSL on Windows Preview.

Could you show the test source/command ?

-Han Sangjin


(Dmitri Gribenko) #9

Hi,

While there wight be an issue in WSL with executable stacks, Swift
does not really need one. If the binary is actually asking for one,
it would be great if we could figure out a way to ask the gold linker
to not mark stacks as executable.

Dmitri

···

On Thu, Jun 16, 2016 at 11:39 PM, Sangjin Han <tinysun.net@gmail.com> wrote:

Hi, Kim.

The test result is same on WSL build 14342.

There is similar report in
https://github.com/Microsoft/BashOnWindows/issues/286 .
MS engineer recognized this and replied that give them feedback on the
uservoice for prioritizing, currently it has only 3 votes.

-Han Sangjin

2016-06-16 21:17 GMT+09:00 Jongsu Kim via swift-dev <swift-dev@swift.org>:

Hi,

This could have been caused by our switch from the BFD linker to gold.
Could you try linking a hello world program using gold linker and
running it in WSL?

I tried to build Swift by not using -fuse-gold option and the result was
same.

Are you sure that PROT_GROWSDOWN is the flag that enables executable
stack? I thought that's what PROT_EXEC is for. I'm not sure what
PROT_GROWSDOWN actually changes, if I were to speculate, I'd say it
could be a marker that means "this is a stack" or maybe even be just a
performance hint.

You are right. The executable stack is enabled by PROT_EXEC.

But Swift shared library's executable stack seems to set PROT_EXEC AND
PROT_GROWSDOWN according to strace.

I don't know what causes Swift shared library to have executable stack
since Febrary 25 snapshot. Febrary 8 snapshot and Swift 2.X branches have no
such executable stack shared library.

Thanks,

-Kim, Jongsu

_______________________________________________
swift-dev mailing list
swift-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-dev

--
main(i,j){for(i=2;;i++){for(j=2;j<i;j++){if(!(i%j)){j=0;break;}}if
(j){printf("%d\n",i);}}} /*Dmitri Gribenko <gribozavr@gmail.com>*/


(Han Sang-jin) #10

Hi,

When linking libswiftCore.so, gold linker with --warn-execstack option
generates following messages.
/usr/bin/ld.gold: warning: lib/swift/linux/x86_64/swift_begin.o: missing
.note.GNU-stack section implies executable stack
/usr/bin/ld.gold: warning: lib/swift/linux/x86_64/swift_end.o: missing
.note.GNU-stack section implies executable stack

I found the web page about the GNU-stack section.
http://en.chys.info/2010/12/note-gnu-stack/

After quick testing in my build system (Linux + execstack -q), I think we
should append one line to stdlib/public/runtime/swift_sections.S, or pass
the proper option to the linker.
The line is
    .section .note.GNU-stack,"",@progbits
and the option is
    '-z noexecstack' (or -Wl,-z -Wl,noexecstack for clang++).

I don't know which method is better, to patch swift_section.S or to patch
linking option.

-Han Sangjin

···

2016-06-17 16:27 GMT+09:00 Dmitri Gribenko <gribozavr@gmail.com>:

Hi,

While there wight be an issue in WSL with executable stacks, Swift
does not really need one. If the binary is actually asking for one,
it would be great if we could figure out a way to ask the gold linker
to not mark stacks as executable.

Dmitri

On Thu, Jun 16, 2016 at 11:39 PM, Sangjin Han <tinysun.net@gmail.com> > wrote:
> Hi, Kim.
>
> The test result is same on WSL build 14342.
>
> There is similar report in
> https://github.com/Microsoft/BashOnWindows/issues/286 .
> MS engineer recognized this and replied that give them feedback on the
> uservoice for prioritizing, currently it has only 3 votes.
>
> -Han Sangjin
>
> 2016-06-16 21:17 GMT+09:00 Jongsu Kim via swift-dev <swift-dev@swift.org
>:
>>
>> Hi,
>>
>>> This could have been caused by our switch from the BFD linker to gold.
>>> Could you try linking a hello world program using gold linker and
>>> running it in WSL?
>>
>>
>> I tried to build Swift by not using -fuse-gold option and the result was
>> same.
>>
>>
>>> Are you sure that PROT_GROWSDOWN is the flag that enables executable
>>> stack? I thought that's what PROT_EXEC is for. I'm not sure what
>>> PROT_GROWSDOWN actually changes, if I were to speculate, I'd say it
>>> could be a marker that means "this is a stack" or maybe even be just a
>>> performance hint.
>>
>>
>> You are right. The executable stack is enabled by PROT_EXEC.
>>
>> But Swift shared library's executable stack seems to set PROT_EXEC AND
>> PROT_GROWSDOWN according to strace.
>>
>> I don't know what causes Swift shared library to have executable stack
>> since Febrary 25 snapshot. Febrary 8 snapshot and Swift 2.X branches
have no
>> such executable stack shared library.
>>
>> Thanks,
>>
>>
>> -Kim, Jongsu
>>
>> _______________________________________________
>> swift-dev mailing list
>> swift-dev@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-dev
>>
>

--
main(i,j){for(i=2;;i++){for(j=2;j<i;j++){if(!(i%j)){j=0;break;}}if
(j){printf("%d\n",i);}}} /*Dmitri Gribenko <gribozavr@gmail.com>*/


(Dmitri Gribenko) #11

The patch would be much better I think. Thank you very much for the
investigation! Could you submit a pull request?

Dmitri

···

On Fri, Jun 17, 2016 at 7:31 AM, Sangjin Han <tinysun.net@gmail.com> wrote:

Hi,

When linking libswiftCore.so, gold linker with --warn-execstack option
generates following messages.
/usr/bin/ld.gold: warning: lib/swift/linux/x86_64/swift_begin.o: missing
.note.GNU-stack section implies executable stack
/usr/bin/ld.gold: warning: lib/swift/linux/x86_64/swift_end.o: missing
.note.GNU-stack section implies executable stack

I found the web page about the GNU-stack section.
http://en.chys.info/2010/12/note-gnu-stack/

After quick testing in my build system (Linux + execstack -q), I think we
should append one line to stdlib/public/runtime/swift_sections.S, or pass
the proper option to the linker.
The line is
    .section .note.GNU-stack,"",@progbits
and the option is
    '-z noexecstack' (or -Wl,-z -Wl,noexecstack for clang++).

--
main(i,j){for(i=2;;i++){for(j=2;j<i;j++){if(!(i%j)){j=0;break;}}if
(j){printf("%d\n",i);}}} /*Dmitri Gribenko <gribozavr@gmail.com>*/


(Han Sang-jin) #12

Please review the PR #3053.

···

2016-06-18 0:17 GMT+09:00 Dmitri Gribenko <gribozavr@gmail.com>:

On Fri, Jun 17, 2016 at 7:31 AM, Sangjin Han <tinysun.net@gmail.com> > wrote:
> Hi,
>
> When linking libswiftCore.so, gold linker with --warn-execstack option
> generates following messages.
> /usr/bin/ld.gold: warning: lib/swift/linux/x86_64/swift_begin.o: missing
> .note.GNU-stack section implies executable stack
> /usr/bin/ld.gold: warning: lib/swift/linux/x86_64/swift_end.o: missing
> .note.GNU-stack section implies executable stack
>
> I found the web page about the GNU-stack section.
> http://en.chys.info/2010/12/note-gnu-stack/
>
> After quick testing in my build system (Linux + execstack -q), I think we
> should append one line to stdlib/public/runtime/swift_sections.S, or pass
> the proper option to the linker.
> The line is
> .section .note.GNU-stack,"",@progbits
> and the option is
> '-z noexecstack' (or -Wl,-z -Wl,noexecstack for clang++).

The patch would be much better I think. Thank you very much for the
investigation! Could you submit a pull request?

Dmitri

--
main(i,j){for(i=2;;i++){for(j=2;j<i;j++){if(!(i%j)){j=0;break;}}if
(j){printf("%d\n",i);}}} /*Dmitri Gribenko <gribozavr@gmail.com>*/


(Dmitri Gribenko) #13

Thank you! I merged your PR, it should be included in the next snapshot.

Dmitri

···

On Fri, Jun 17, 2016 at 2:26 PM, Sangjin Han <tinysun.net@gmail.com> wrote:

Please review the PR #3053.

2016-06-18 0:17 GMT+09:00 Dmitri Gribenko <gribozavr@gmail.com>:

On Fri, Jun 17, 2016 at 7:31 AM, Sangjin Han <tinysun.net@gmail.com> >> wrote:
> Hi,
>
> When linking libswiftCore.so, gold linker with --warn-execstack option
> generates following messages.
> /usr/bin/ld.gold: warning: lib/swift/linux/x86_64/swift_begin.o: missing
> .note.GNU-stack section implies executable stack
> /usr/bin/ld.gold: warning: lib/swift/linux/x86_64/swift_end.o: missing
> .note.GNU-stack section implies executable stack
>
> I found the web page about the GNU-stack section.
> http://en.chys.info/2010/12/note-gnu-stack/
>
> After quick testing in my build system (Linux + execstack -q), I think
> we
> should append one line to stdlib/public/runtime/swift_sections.S, or
> pass
> the proper option to the linker.
> The line is
> .section .note.GNU-stack,"",@progbits
> and the option is
> '-z noexecstack' (or -Wl,-z -Wl,noexecstack for clang++).

The patch would be much better I think. Thank you very much for the
investigation! Could you submit a pull request?

Dmitri

--
main(i,j){for(i=2;;i++){for(j=2;j<i;j++){if(!(i%j)){j=0;break;}}if
(j){printf("%d\n",i);}}} /*Dmitri Gribenko <gribozavr@gmail.com>*/

--
main(i,j){for(i=2;;i++){for(j=2;j<i;j++){if(!(i%j)){j=0;break;}}if
(j){printf("%d\n",i);}}} /*Dmitri Gribenko <gribozavr@gmail.com>*/


(Jongsu Kim) #14

Hi, Han

Your PR is very helpful. Thanks a lot.

The Foundation repo has some assembly files similar to swift_sections.S as
follows:
  swift-corelibs-foundation/CoreFoundation/String.subproj/
    CFCharacterSetData.S
    CFUniCharPropertyDatabase.S
    CFUnicodeData.S

The generated libFoundation.so is marked as executable stack on Linux, too.

Would you do me a favor of posting simlar PR to the Foundation Project?
Very sorry, I am a git novice.

Thanks.

-Kim, Jongsu

···

On Sat, Jun 18, 2016 at 5:30 PM, Dmitri Gribenko <gribozavr@gmail.com> wrote:

Thank you! I merged your PR, it should be included in the next snapshot.

Dmitri

On Fri, Jun 17, 2016 at 2:26 PM, Sangjin Han <tinysun.net@gmail.com> > wrote:
> Please review the PR #3053.
>
> 2016-06-18 0:17 GMT+09:00 Dmitri Gribenko <gribozavr@gmail.com>:
>>
>> On Fri, Jun 17, 2016 at 7:31 AM, Sangjin Han <tinysun.net@gmail.com> > >> wrote:
>> > Hi,
>> >
>> > When linking libswiftCore.so, gold linker with --warn-execstack option
>> > generates following messages.
>> > /usr/bin/ld.gold: warning: lib/swift/linux/x86_64/swift_begin.o:
missing
>> > .note.GNU-stack section implies executable stack
>> > /usr/bin/ld.gold: warning: lib/swift/linux/x86_64/swift_end.o: missing
>> > .note.GNU-stack section implies executable stack
>> >
>> > I found the web page about the GNU-stack section.
>> > http://en.chys.info/2010/12/note-gnu-stack/
>> >
>> > After quick testing in my build system (Linux + execstack -q), I think
>> > we
>> > should append one line to stdlib/public/runtime/swift_sections.S, or
>> > pass
>> > the proper option to the linker.
>> > The line is
>> > .section .note.GNU-stack,"",@progbits
>> > and the option is
>> > '-z noexecstack' (or -Wl,-z -Wl,noexecstack for clang++).
>>
>> The patch would be much better I think. Thank you very much for the
>> investigation! Could you submit a pull request?
>>
>> Dmitri
>>
>> --
>> main(i,j){for(i=2;;i++){for(j=2;j<i;j++){if(!(i%j)){j=0;break;}}if
>> (j){printf("%d\n",i);}}} /*Dmitri Gribenko <gribozavr@gmail.com>*/
>
>

--
main(i,j){for(i=2;;i++){for(j=2;j<i;j++){if(!(i%j)){j=0;break;}}if
(j){printf("%d\n",i);}}} /*Dmitri Gribenko <gribozavr@gmail.com>*/