On 14.12.2023 16:20, Roger Pau Monné wrote: > On Thu, Dec 14, 2023 at 02:53:13PM +0100, Jan Beulich wrote: >> On 14.12.2023 14:37, Roger Pau Monné wrote: >>> On Thu, Dec 14, 2023 at 12:18:13PM +0100, Jan Beulich wrote: >>>> On 14.12.2023 11:17, Roger Pau Monne wrote: >>>>> The minimal function size requirements for livepatch are either 5 bytes >>>>> (for >>>>> jmp) or 9 bytes (for endbr + jmp) on x86, and always 4 bytes on Arm. >>>>> Ensure >>>>> that distance between functions entry points is always at least of the >>>>> minimal >>>>> required size for livepatch instruction replacement to be successful. >>>>> >>>>> Add an additional align directive to the linker script, in order to >>>>> ensure that >>>>> the next section placed after the .text.* (per-function sections) is also >>>>> aligned to the required boundary, so that the distance of the last >>>>> function >>>>> entry point with the next symbol is also of minimal size. >>>>> >>>>> Note that it's possible for the compiler to end up using a higher function >>>>> alignment regardless of the passed value, so this change just make sure >>>>> that >>>>> the minimum required for livepatch to work is present. >>>> >>>> That's a possibility which we don't need to be concerned about. Yet isn't >>>> it >>>> also possible that we override a larger, deemed better (e.g. >>>> performance-wise) >>>> value? >>> >>> I'm kind of confused, the compiler will always choose the higher >>> alignment. >> >> Will it? Before writing the reply I went through gcc's respective doc >> section, without finding such a guarantee. > > Hm, yes, checked with godbolt now and GCC behaves the opposite of > clang, and will always attempt to honor the alignment passed in > falign-functions. > > Maybe for release builds we should select a 16b alignment on x86?
Might make sense, yes. Iirc there was a time where 16-byte alignment was the default for functions in gcc. Jan
