Linux + Clang + execstack

[Magnus Ihse Bursie]

On 2018-09-12 18:35, Martin Buchholz wrote:
> On Wed, Sep 12, 2018 at 4:01 AM, Magnus Ihse Bursie
> <magnus.ihse.bursie at oracle.com> wrote:
>> On 2018-09-05 20:59, Martin Buchholz wrote:
>>
>> So ... Magnus, are you happy with the current state of the proposed patch?
>>
>> I'm sorry Martin, but I can't figure out what the current state is. I tried
>> backtracking the discussion but failed. :( Can you please repost the
>> currently proposed patch?
> http://cr.openjdk.java.net/~martin/webrevs/jdk/noexecstack/noexecstack.patch
I'm not entirely happy, but it'll have to do. The problem here is that 
the underlying structure of the flags handling is still not good so this 
probably cannot be expressed better than this.

Do you have a JBS issue?

/Magnus

>
>> On Tue, Sep 4, 2018 at 11:50 PM, Magnus Ihse Bursie
>> <magnus.ihse.bursie at oracle.com> wrote:
>>>
>>> For the gcc toolchain this can not be the case:
>>> # Minimum supported linker versions, empty means unspecified
>>> TOOLCHAIN_MINIMUM_LD_VERSION_gcc="2.18"
>>>
>>> We make sure we have an ld that supports the basic flags we assume.
>>
>> feature tests are better than version tests.
>>
>> I've heard that argument many times, and I've never agreed with it. In some
>> cases, feature tests work. They typically work if someone has designed a
>> clear API and included a feature test in it. A lot of additional POSIX
>> functionality works that way. This means that you can rest assure that if
>> the feature is present, then you know what you are going to get.
>>
>> In most of the rest of the world, functionality does not raise to that
>> golden standard. Gcc adds a flag in one version, but it's buggy. A later
>> version fixes the bugs. A later version still changes the behavior of the
>> flag. Functionality that we depend on works or does not works depending on
>> the intersection of things like our code, compiler version, operating
>> system, and so on.
>>
>> In my experience, it's a rare thing for a feature test to actually work.
>> Version tests, on the other hand, tests against a specific setup, that can
>> be tested and proven to work. The downside of version tests is that they are
>> often open-ended; we say that "anything above this version is supposed to
>> work", even though we have not tested with gcc 8 or 9. The alternative is to
>> say that "we've tested this between gcc 4.7 and 7.3 and will only support it
>> for this version span", but that is in most cases more likely to break when
>> gcc 8 comes along.
> Specific version tests are in principle more accurate, but they
> require a level of testing and maintenance that is unlikely to be seen
> in the real world.  The received wisdom is that one should prefer
> feature tests whenever possible and I agree with that as well, based
> on decades of experience.
>
> Sometimes you need something in between, e.g. replacing a
> configure-time check with a run-time check.