On 2018-09-12 18:35, Martin Buchholz wrote:
On Wed, Sep 12, 2018 at 4:01 AM, Magnus Ihse Bursie
<magnus.ihse.bur...@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.bur...@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.
