This is an archive of the discontinued LLVM Phabricator instance.

Fix vtable not receiving hidden visibility when using push(visibility)
ClosedPublic

Authored by jakehehrlich on Nov 3 2017, 6:23 PM.

Diff Detail

Repository
rL LLVM

Event Timeline

jakehehrlich created this revision.Nov 3 2017, 6:23 PM
rjmccall edited edge metadata.Nov 3 2017, 11:43 PM

Hmm. We're calling this from getAddrOfVTable, which can be used to get a declaration for an external v-table, but setGlobalVisibility appears to set visibility as if we were emitting a definition. Among other reasons, the difference is important because we generally don't honor implicit visibility when emitting external references. The pragma should be treated as an explicit source of visibility — IIRC we model it by actually adding a visibility attribute — but I think your patch would cause us to use hidden visibility on an external v-table declaration even if the only reason we thought it was hidden was that we were compiling under -fvisibility=hidden.

The logic for declarations is currently defined in the function setLinkageAndVisibilityForGV in CodeGenModule.cpp. That's a static function in that file: we could just add it to CodeGenModule, but I think there's a better solution: we could add a ForDefinition_t flag to CGM::setGlobalVisibility and then unify these two implementations.

Hmm. We're calling this from getAddrOfVTable, which can be used to get a declaration for an external v-table, but setGlobalVisibility appears to set visibility as if we were emitting a definition. Among other reasons, the difference is important because we generally don't honor implicit visibility when emitting external references. The pragma should be treated as an explicit source of visibility — IIRC we model it by actually adding a visibility attribute — but I think your patch would cause us to use hidden visibility on an external v-table declaration even if the only reason we thought it was hidden was that we were compiling under -fvisibility=hidden.

The logic for declarations is currently defined in the function setLinkageAndVisibilityForGV in CodeGenModule.cpp. That's a static function in that file: we could just add it to CodeGenModule, but I think there's a better solution: we could add a ForDefinition_t flag to CGM::setGlobalVisibility and then unify these two implementations.

I'm missing some background lingo here. What is the meaning of "a declaration" and "a definition" here? It sounds like setLinkageAndVisibilityForGV will be called if the GlobalValue is synthetically generated (as vtables are) and doesn't have a corresponding deceleration in source? And setGlobalVisibility will be used to set visibility of GlobalValues mentioned in source?

Adding cfe-commits. (In the future, please make sure to CC that list instead of llvm-commits for clang changes.)

I'm missing some background lingo here. What is the meaning of "a declaration" and "a definition" here?

In most cases, we only emit the vtable for a class in one object file. Informally, we can call that the "definition" of the vtable, as an analogy to variables and functions. See also http://itanium-cxx-abi.github.io/cxx-abi/abi.html#vague-vtable .

Adding cfe-commits. (In the future, please make sure to CC that list instead of llvm-commits for clang changes.)

I'm missing some background lingo here. What is the meaning of "a declaration" and "a definition" here?

In most cases, we only emit the vtable for a class in one object file. Informally, we can call that the "definition" of the vtable, as an analogy to variables and functions. See also http://itanium-cxx-abi.github.io/cxx-abi/abi.html#vague-vtable .

LLVM also distinguishes between a declaration (a Function or GlobalVariable which is presumed to be defined in a different Module) vs. a definition.

  1. Added a ForDefinition parameter to setGlobalVisibility and merged visibility setting behaviors for setGlobalVisibility and setLinkageAndVisibilityForGV
  2. Renamed setLinkageAndVisibilityForGV to setLinkageForGV
  3. refactored calls to these two functions to match their new form.
rjmccall accepted this revision.Nov 18 2017, 12:32 AM

Looks great, thanks!

This revision is now accepted and ready to land.Nov 18 2017, 12:32 AM
This revision was automatically updated to reflect the committed changes.

This test was failing on windows machines. I'm hoping this change (adding "_cc1" to "%clang") will resolve this because %clang_cc1 shouldn't behave any differently on windows.

When I changed the test to add "_cc1" I got rid of the temporary file. Well for some reason on windows we're still getting different output so we need the temporary file to debug things.

You probably just need to pass a "-triple" flag so we don't use Windows mangling or something like that.