We encountered an issue where we're linking LTO'd rust and c++ code together and the c++ code is built with -fsanitize=cfi. The link invoked by rustc fails with

  = note: lld: error: inconsistent LTO Unit splitting (recompile with -fsplit-lto-unit)

We're hitting this issue because CFI unconditionally expects all participating bitcode to define EnableSplitLTOUnit as 1 in their modules, but CFI always checks this by reading the module summaries. Now all the c++ bitcode provides these summaries because -fsplit-lto-unit is implicitly added by clang when using -fsanitize=cfi, but rust seems to only provide these summaries under thinlto.

It looks like whether or not module summaries are included in the emitted bitcode is controlled by LLVMRustModuleSerialize which either adds the ThinLTOBitcodeWriterPass or does a normal bitcode write via WriteBitcodeToFile. ThinLTOBitcodeWriterPass will unconditionally add the summaries, but WriteBitcodeToFile won't. That just invokes the BitcodeWriterPass but without setting the EmitSummaryIndex to true to emit the summaries.

My question is: should rustc under -Clto=fat also be unconditionally emitting the summaries just like with thinlto? I think in practice the summaries generally aren't needed with full (fat) lto since summaries might not be needed for a single monolithic link of just rust code, but I think in general a bitcode compilation of some rust won't know if it's participating in a monolithic link or something else that might need these summaries, hence they should always be emitted. Thoughts?

1 post - 1 participant

Read full topic