On Mon Jan 22 18:00:34 2024 +0000, Alexandre Julliard wrote:
Import libraries are not regular static libs, they don't contain real code, so it wouldn't make sense to have them participate in LTO.
Unfortunately it doesn't seem like they're built with LTO to begin with (and even if I disable it, it's the same). They still contain just jump stubs and actual code even without `-ffat-lto-objects`, so they're already without LTO from what I can see (and still fails, for whatever reason). "Actual code" means actual compiled object files, because LTO stores only the internal IR without fat mode. Maybe LTO still tries to resolve/import them even if they don't contain LTO IR bytecode…
I did find a somewhat hacky solution using the `no_reorder` attribute. Per the documentation it guarantees the function is not reordered between top level asms, so we can do some assembler magic:
```c __ASM_GLOBAL_FUNC( _chkstk, /* same asm as normal */ ) asm(".if 0"); void __attribute__((__no_reorder__,__naked__)) _chkstk(void) { asm(""); } asm(".endif"); ```
Note the `naked` attribute with the empty asm, which tells LTO that it can't know the contents of the function (so it can't optimize anything which would be wrong). And the `no_reorder` which guarantees the function is placed between the top level asm statements. And of course this could be integrated into the macro.
It works, but I'm guessing this is too much of a hack for upstream?