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.
Details
- Reviewers
tejohnson mehdi_amini • espindola
Diff Detail
- Build Status
Buildable 11491 Build 11491: arc lint + arc unit
Event Timeline
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