This is an archive of the discontinued LLVM Phabricator instance.

[lld][COFF] Add support for overriding weak symbols in LLVM bitcode input
ClosedPublic

Authored by ayzhao on Sep 1 2022, 4:06 PM.

Details

Summary

LLVM bitcode contains support for weak symbols, so we can add support
for overriding weak symbols in the output COFF even though COFF doesn't
have inherent support for weak symbols.

The motivation for this patch is that Chromium is trying to use libc++'s
assertion handler mechanism, which relies on weak symbols [0], but we're
unable to perform a ThinLTO build on Windows due to this problem [1].

[0]: https://reviews.llvm.org/D121478
[1]: https://crrev.com/c/3863576

Diff Detail

Event Timeline

ayzhao created this revision.Sep 1 2022, 4:06 PM
Herald added a project: Restricted Project. · View Herald TranscriptSep 1 2022, 4:06 PM
ayzhao requested review of this revision.Sep 1 2022, 4:06 PM
Herald added a project: Restricted Project. · View Herald TranscriptSep 1 2022, 4:06 PM
ayzhao added a reviewer: rnk.Sep 1 2022, 4:07 PM
ayzhao added a subscriber: aeubanks.

Thanks for your effort on this! This looks mostly good to me. It's a shame that weak symbols from bitcode has to be handled differently than regular weak symbols from object files.

FWIW, I've got a set of testcases for weak symbol interactions in mingw, and a couple of them used to fail with LTO before; with this patch in place, all except one pass.

The one that still fails does this:

__attribute__((weak)) void func(void);
void doCall(void) {
    if (func)
        func();
}

If this is linked without any definition of func, it still fails with an undefined reference. (In the regular object file form, there's a weak undefined named func, which points at an absolute symbol (with a autogenerated unique name) with the value zero. If there's no other definition of func, the symbol resolves as the absolute address zero.)

lld/COFF/Symbols.h
151

Would it be good to mention that this only is tracked for bitcode/LTO symbols? For object files, weak symbols are handled in a different way.

165

Nit: This looks like an unintentded indentation change?

lld/test/COFF/weak-override.ll
8

I think it'd be useful to test that linking without the strong definition also succeeds.

hans added a subscriber: hans.Sep 5 2022, 5:53 AM

Very nice!

I'm still curious how our non-ThinLTO builds worked. I assume there is some nuance to "COFF doesn't support weak symbols"?

I'm still curious how our non-ThinLTO builds worked. I assume there is some nuance to "COFF doesn't support weak symbols"?

COFF does have weak aliases, and at least within the mingw/GNU ecosystem, there's ways that __attribute__((weak)) is mapped to weak aliases, which mostly works to emulate ELF style weak symbols. Not sure if this is usable when building in MSVC mode or not - that could be what you've been using.

ayzhao updated this revision to Diff 458189.Sep 6 2022, 9:26 AM
ayzhao marked 3 inline comments as done.

code review comments

ayzhao updated this revision to Diff 458199.Sep 6 2022, 9:56 AM

fix test

rnk accepted this revision.Sep 6 2022, 12:04 PM

I'm still curious how our non-ThinLTO builds worked. I assume there is some nuance to "COFF doesn't support weak symbols"?

COFF does have weak aliases, and at least within the mingw/GNU ecosystem, there's ways that __attribute__((weak)) is mapped to weak aliases, which mostly works to emulate ELF style weak symbols. Not sure if this is usable when building in MSVC mode or not - that could be what you've been using.

Yes, and I think it would be quite awkward for us to try to model bitcode weak symbols with weak aliases. This new flag seems like a better way, thanks!

lgtm

This revision is now accepted and ready to land.Sep 6 2022, 12:04 PM
ayzhao updated this revision to Diff 458250.Sep 6 2022, 1:01 PM

fix spacing

This revision was landed with ongoing or failed builds.Sep 8 2022, 10:17 AM
This revision was automatically updated to reflect the committed changes.