This is an archive of the discontinued LLVM Phabricator instance.

[Verifier] Reject dllexport with non-default visibility
ClosedPublic

Authored by MaskRay on Sep 3 2022, 10:18 PM.

Details

Summary

Add a visibility check for dllimport and dllexport. Note: dllimport with a
non-default visibility (implicit dso_local) is already rejected, but with a less
clear dso_local error.

The MC level visibility MCSA_Exported (D123951) is mapped from IR level
default visibility when dllexport is specified. The D123951 error is now very
difficult to trigger (needs to disable the IR verifier).

Diff Detail

Event Timeline

MaskRay created this revision.Sep 3 2022, 10:18 PM
Herald added a project: Restricted Project. · View Herald TranscriptSep 3 2022, 10:18 PM
MaskRay requested review of this revision.Sep 3 2022, 10:18 PM
Herald added a project: Restricted Project. · View Herald TranscriptSep 3 2022, 10:18 PM
mstorsjo accepted this revision.Sep 5 2022, 12:45 AM

LGTM

llvm/test/Verifier/dllstorage.ll
7

I presume we can't easily get the symbol names into these error messages?

This revision is now accepted and ready to land.Sep 5 2022, 12:45 AM
MaskRay updated this revision to Diff 458041.Sep 5 2022, 10:25 AM
MaskRay marked an inline comment as done.

improve test

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

Hi! Sorry for not raising this issue prior to commit. The dllimport restriction seems correct to us. However, in PlayStation we are using dllexportclass=dllexport visibility=protected GlobalValues in LLVM IR. The protected visibility indicates that the symbol cannot be preempted and could be exported and dllexport indicates that it should be exported. This allows for implementing export control from C/C++ source code. This change has made this usage illegal. It doesn't makes sense semantically to restrict dllexport to visibility=default in LLVM IR, the restriction should be to visibility != hidden as hidden symbols cannot be exported by ELF linkers. Thanks.

Hi! Sorry for not raising this issue prior to commit. The dllimport restriction seems correct to us. However, in PlayStation we are using dllexportclass=dllexport visibility=protected GlobalValues in LLVM IR. The protected visibility indicates that the symbol cannot be preempted and could be exported and dllexport indicates that it should be exported. This allows for implementing export control from C/C++ source code. This change has made this usage illegal. It doesn't makes sense semantically to restrict dllexport to visibility=default in LLVM IR, the restriction should be to visibility != hidden as hidden symbols cannot be exported by ELF linkers. Thanks.

Oh, didn't know. Pushed 97d00b72a2b0a7aca631e1402a647f32c4e8bafb to allow dllexport protected.
Does PlayStation need to relax the clang check D133266, too? (I have noticed that this combo makes sense but rejected it for simplicity.)

Hi! Sorry for not raising this issue prior to commit. The dllimport restriction seems correct to us. However, in PlayStation we are using dllexportclass=dllexport visibility=protected GlobalValues in LLVM IR. The protected visibility indicates that the symbol cannot be preempted and could be exported and dllexport indicates that it should be exported. This allows for implementing export control from C/C++ source code. This change has made this usage illegal. It doesn't makes sense semantically to restrict dllexport to visibility=default in LLVM IR, the restriction should be to visibility != hidden as hidden symbols cannot be exported by ELF linkers. Thanks.

Oh, didn't know. Pushed 97d00b72a2b0a7aca631e1402a647f32c4e8bafb to allow dllexport protected.
Does PlayStation need to relax the clang check D133266, too? (I have noticed that this combo makes sense but rejected it for simplicity.)

Thanks, much appreciated :) I think we should relax the D133266 as well for completeness and to prevent customers having to edit their source code when it worked with previous compilers. However, I have spotted a potential problem with D133266. I will add a comment on that review.