[arch-dev-public] Changing compilation flags

[Daniel Micay]

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