On Wed, 2017-07-05 at 21:06 +0300, Evangelos Foutras wrote: > On 5 July 2017 at 19:51, Daniel Micay <[email protected]> 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 > > > <[email protected]> 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.
