Linux + Clang + execstack

[Magnus Ihse Bursie]

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?


>
> On Tue, Sep 4, 2018 at 11:50 PM, Magnus Ihse Bursie 
> <magnus.ihse.bursie at oracle.com <mailto: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.


> Because there are various linkers in play (old GNU ld, gold, lld, 
> macosx ld, BSD ld) and we'd like our compilers to work the same way on 
> various platforms, I'm vaguely unhappy with 
> TOOLCHAIN_MINIMUM_LD_VERSION_gcc. It looks 
> like TOOLCHAIN_EXTRACT_LD_VERSION is another place where we conflate 
> toolchains and operating systems.

The linker is often in a situation where it's conflated between 
toolchain and operating system. :-) I think it's more due to how the 
linker is positioned/perceived, than due to a fault of ours. On Windows, 
for instance, the linker is clearly a part of the toolchain. On solaris, 
there's a system linker and the solstudio does not distribute any linker 
on their own. On linux, the gcc toolchain actually allows you to select 
linker (gold, etc), but arguably they belong to the gcc toolchain rather 
than the OS.

>     We can add a similar check for the clang toolchain, if you want.
>
>     Mixing and matching compilers and linkers willy-nilly is not a
>     supported build option
>
>
> As always, I am for portability and for toolchain competition.  I'd 
> like to be able to build with Intel's icc toolchain.

That might be a noble goal, but it's not realistic. There's a huge cost 
involved with supporting different combinations; the combinatorial 
matrix blows up quickly, and if these different combinations are not 
regularly tested, they *will* break.

That being said, I'm too in general in favor of supporting more rather 
than less. But only as long as there's no high price to pay for the 
common/reasonable combinations.

/Magnus