This is an archive of the discontinued LLVM Phabricator instance.

Don't internalize dllexport functions.
Needs ReviewPublic

Authored by filcab on Oct 25 2017, 12:00 PM.

Details

Summary

The PS4 platform also has dllexport, but doesn't have the /EXPORT:sym
mechanism that COFF uses (it does have something like that (specific for
dllexport) in object files, though.
It seems to me that lld shouldn't ever be removing dllexported symbols. On
COFF, it eventually knows this and uses R.VisibleInRegularObj eventually gets
set to true from the /EXPORT:sym commands. Not on other platforms.

Event Timeline

filcab created this revision.Oct 25 2017, 12:00 PM
pcc added a subscriber: pcc.Oct 25 2017, 12:19 PM

It looks like this will only work for full LTO, and not ThinLTO.

How does your linker decide which symbols are exported from regular object files? Should there instead be a mechanism to get that information from the lto::InputFile?

In D39302#906950, @pcc wrote:

It looks like this will only work for full LTO, and not ThinLTO.

How does your linker decide which symbols are exported from regular object files? Should there instead be a mechanism to get that information from the lto::InputFile?

Regular object files (ELF-like) have a .linker_cmd section which has a few possible commands. One of them is "This symbol is dllexported.
I'll look into the thinLTO case. Is the test in an appropriate place, btw?

Thank you,

Filipe

What's the meaning of (old) "norename" in thin LTO? I couldn't track it down, but it seems like it might be helpful. If it's to tell whomever imports the module that that function can't be renamed, then I think dllexported functions should be tagged as such.
I can see a case for allowing an importing module to inline dllexport functions without allowing it to delete the original, though. I'm not sure if norename (now NotEligibleToImport) allows this.

Thoughts?

Filipe

espindola edited reviewers, added: espindola; removed: rafael.Mar 15 2018, 9:08 AM