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 > 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.
