build: use PIE objects for non-PIC static libraries if b_pie=true

[bonzini]

If static_library is used for a convenience library (e.g. for link_whole), the library should in principle not need position independent code. However, if the executables that the libraries is linked to are PIE, the non-PIC objects in the static library will cause linker errors. To avoid this, obey b_pie for static libraries if either b_staticpic=false or they use pic: false.

Without this patch, a project that only uses static libraries as convenience libraries cannot use b_staticpic=false, because the correct setting would be, so to speak, b_staticpic=$b_pie. This causes a massive slowdown on some QEMU benchmarks (up to 20%). We can work it around for now while we still have wrappers upon wrappers around Meson, but in the long run this should be fixed.

But actually, this patch also provides a performance improvement if b_pie=true, because b_staticpic=true b_pie=true is also slower than the b_staticpic=false b_pie=true combo that is now fixed. This is because -fPIC produces worse code than -fPIE. On the aforementioned benchmark:

b_staticpic=false b_pie=false               0.5s
b_staticpic=true b_pie=true                 0.6s
---
b_staticpic=false b_pie=true unpatched      linking fails
b_staticpic=false b_pie=true patched        0.53s

[jpakkane]

Just a note that traditionally these sort of behaviour changes have been a bit dangerous. Usually someone's project breaks. Are there any known cases where this might happen?

[bonzini]

I don't know any, in fact I'm trying to make Meson more conservative: currently it's assuming that b_staticpic=false static libraries are only ever used in position-dependent code, while my patch makes the libraries acceptable for PIEs as well.

[bonzini]

Ping?

[jpakkane]

This requires thinking about the implications fairly thoroughly. I'll try to get that done this weekend.

[jpakkane]

One thought that came up was that maybe b_staticpic is the wrong thing to do. What if we could change it to, say, b_statictype that could have values none, pic or pie? It would seem to express the intent better. But would it help in solving the issue?

[bonzini]

It would not help because there is no way to express that you want b_statictype equal to none if b_pie=false, and equal to pieifb_pie=yes`.

I think you are seeing this as an optimization that allows one to use b_staticpic=false; instead I see it as a bug fix, because b_staticpic=false or pic: false are the right choice more often than not, but they're currently broken if b_pie=true. Imagine if the inverse of b_staticpic were named b_static_libraries_linked_to_executables_only: that makes it more obvious if a project wants it true or false---but then, we have the bug that b_staticpic=false it does not work if b_pie=true.

(Related to this would it make sense to deprecate installing static_libraries if b_staticpic is false?).

[jpakkane]

I guess the problem here is that the original design for b_staticpic was too limited. Instead of a boolean it should have had the values alwayspic, never, alwayspie and pieifb_pieistrue (it should also have a better name in that case, but I digress). The question is whether we could achieve that without breaking backwards compatibility (too much).

[bonzini]

Yeah that would be more precise, but then you'd also want a pie keyword argument to static_library and I think that would be overkill.

In my opinion even the pie keyword argument for executables is overkill; b_pie should be enough. It was probably done for consistency with pic in static libraries but the two are different. Having pic for static libraries makes sense because convenience libraries for executables are a common usage of static_library, but there's no equivalent use of pie`.

This is also why I am okay with a boolean b_staticpic: if you remove pie from executable, then the never and alwayspie cases aren't needed and the remaining two might as well be true and false.

[jpakkane]

Thinking about this more, pie is actually unnecessary because you can do override_options: b_pie=false`. It's not as convenient, though.

There are really three cases that I can see.

• PIC, if the library ends up in a shared library
• PIE, if the library ends up in an executable that needs to be PIE
• nothing, for absolute performance (according to the Internet, PIE has a ~10% performance penalty)

On some platforms (mac?) the last two are the same, all code is at least PIE.

You can't know where a library will be used when it is declared so barring advances in clairvoyance we can't autodetect that. So let's speculate some instead. If we had b_pie as currently and a kwarg pi_type for static libraries that takes values none, pic or pie, would that be sufficient for all cases? From what I can see:

• if you know a static lib eventually goes to a shared lib, you can do `pi_type: 'pic'
• Toggling b_pic would automatically make static libraries switch to the desired picness
• for individual executables you could override b_pic as necessary

The downside is that to match the current behaviour, the default value should be pic.

[bonzini]

You can't know where a library will be used when it is declared so barring advances in clairvoyance we can't autodetect that

Right, this is why I would like to warn on installing pic: false libraries. Those are meant to be linked with executables (in the current project) because once the static library it's installed it could end up linked with a shared library. And in order to link with executables, non-PIC libraries must obey b_pie.

(More precisely therefore this PR should be "use PIE objects for non-PIC static libraries if b_pie=true").

If we want to have PIE libraries in non-PIE projects or vice versa, adding override_options to build targets other than executable is probably the way to go.

The downside is that to match the current behaviour, the default value should be pic.

Yeah, the problem with pi_type is that it preserves the "flat" ternary choice while it's actually a decision tree:

• do you every want to link the static library to a shared library? (pic, b_staticpic)
• if not, are your executables of interest PIE? (b_pie with override_options and/or pie—none of the two exists in static_library but it can be added later)

I have no problem with the default for b_staticpic being the safe value, i.e. true. On the other hand the "I want absolute performance for a binary or two but otherwise b_pie=true" case seems pretty contrived.

[jpakkane]

Just in case: this MR gets an exception to get merged in after RC1 (if necessary).

[jpakkane]

I went through this again and it clearly improves the situation for an important use case. I could not come up with a case where it would break things. If they exist, hopefully they crop up during the RC (though the pessimist in me expects that to only happen after the actual release :( ). f that happens we may need to revert this, but that's a different problem then.

In case problems occur, we should consider overhauling the pic/pie options under a single toggle. The current split is confusing.