-fwhole-program-vtables breaks in combination with -ffat-lto-objects

[Jannik2099]

the following

#include <stdexcept>

struct Foo : std::runtime_error {
    Foo() : runtime_error("") {}
};

Foo foo{};

when built into an object file with
clang++ -flto=thin -fwhole-program-vtables -ffat-lto-objects -fPIC -fvisibility=hidden -c foo.cpp -o foo.o
and then linked into a shared library with
clang++ -flto=thin -shared foo.o -o foo.so
will fail with
ld.lld: error: undefined hidden symbol: vtable for Foo

Removing either the -fwhole-program-vtables or -ffat-lto-objects when compiling the object file works fine.

Note that this isn't related to this specific underlying type, I only discovered it with std::runtime_error first. Reproduces on libstdc++ and libc++ (when linking dynamically)

[mysterymath]

@ilovepi

[PiJoules]

I believe the vtable should be emitted in this TU since there's no non-pure, non-inline, virtual functions. Without -ffat-lto-objects I can see the vtable is emitted in the IR but with that flag I see the vtable emitted as @_ZTV3Foo = external hidden unnamed_addr constant { [5 x ptr] }, align 8 which doesn't have a definition.

[ilovepi]

I'd guess you need to also pass -ffat-lto-objects when linking the .so. The link command you gave won't use the .llvm.lto section to do WPD in a way that makes sense. I'm looking at this case now, its possible that we're missing some additional handling for WPD cleanup in the FatLTO pipeline.

[ilovepi]

yeah, this seems like a bug when we use the object code and WPD was passed. Thanks for the simple reproducer, I'll start working on a fix.

[ilovepi]

I was surprised we didn't run into this in Fuchsia, but now that I'm looking, I see the undesirebale tranform happens in EmbedBitcodePass, when we use the ThinLTOBitcodeWriter and it tries to promote type ids. That is the correct thing to do for the ThinLTO linking via bitcode and WPD, but breaks a lot of things for the non-LTO object code.

We don't use ThinLTO much in Fuchsia with C++ code, so that's likely why we haven't run into this much yet. I think I have a way to fix this in the short term, without going back to module cloning.

[ilovepi]

Looking more, this seems hard to solve without cloning the module. We can at least only clone it in the emitbitcodepass, but that is still suboptimal.

To avoid cloning, we'd need to roll back all the IR changes that the ThinLTOBitcodeWriter introduces. Or at least the ones that affect vtables and linkage.

I can put up a patch tomorrow that will address the problem, but it will take longer to design a solution that would work without cloning.