On Wed, 2017-07-05 at 21:06 +0300, Evangelos Foutras wrote:
On 5 July 2017 at 19:51, Daniel Micay <danielmicay@gmail.com> wrote:
On Wed, 2017-07-05 at 12:36 +0300, Evangelos Foutras wrote:
On 2 July 2017 at 19:19, Daniel Micay via arch-dev-public <arch-dev-public@archlinux.org> wrote:
Using -fno-plt would be a nice tiny little performance boost at runtime but then it's important to make sure everything is compiled with -Wl,- z,now and there might be programs ignoring LDFLAGS but respecting CFLAGS. Ideally -z now would be the default in the linker first. If we aren't going to patch the default, then I think a configure flag for that needs to land upstream.
It's also worth noting that clang does not support the -fno-plt option and I couldn't find any discussions about adding support for it.
If it's only a tiny performance improvement, I strongly believe we should skip it for now.
There's no loss of compatibility from only some code using it. The only issue with it is that immediate binding *must* be used to support it, so if CFLAGS is respected then LDFLAGS *must* be respected, or immediate binding needs to be set as the default in the linker(s).
By lacking support I meant that clang aborts the compilation and throws an error with -fno-plt:
clang-4.0: error: unknown argument: '-fno-plt'
I briefly discussed this on IRC with Bartłomiej and he finds it acceptable to add workarounds (removing -fno-plt from CFLAGS) to the few dozen packages that use clang for building (not counting AUR packages).
I disagree and do not consider insignificant performance increases to be sufficient justification to add GCC 6+ specific options to the default CFLAGS and necessitate adding workarounds to packages that do not use the default compiler.
And then there is the (minor) issue you highlight, and possibly other issues we don't know about (since -fno-plt hasn't been adopted by any other distro).
On a related note, it is unclear to me whether you mean that packages might fail to build (and/or run?) if they only respect CFLAGS but not LDFLAGS, or that a package might fail to build (and/or run?) because one of its dependencies didn't respect LDFLAGS.
Using -fno-plt requires linking objects built with the code compiled with that option using -Wl,-z,now but I don't think a build failure will happen if it's missing. It will be a fault (not memory corruption) at runtime when it tries to use a function via -fno-plt calling convention that hasn't been lazily linked via PLT calling convention. It's likely never going to be a subtle failure that isn't blatantly obvious though. So for example, lets say a static library respects CFLAGS and gets compiled with -fno-plt. Lets say it's linked into an executable that does not respect LDFLAGS. Alternatively, the executable build system may respect LDFLAGS but overrides CFLAGS like 'CFLAGS := -O2' or something similar, which would break in the same way. So I think it would be a good idea to flip the default to -z,now in the linker if we're going to use -fno-plt. I think they'd take a patch for that upstream. Clang issue could be avoided with a 1 line patch adding another no-op flag and they'd take that upstream. It's harmless to use the slower lazy linking calling convention when -fno-plt is passed. -fno-plt code is fully compatible with non -fno-plt code, the only requirement is that -fno-plt code is linked with -Wl,-z,now which works fine for non -fno-plt code too and is desirable for security either way.