Commit Graph

4 Commits

Author SHA1 Message Date
Pirama Arumuga Nainar 078279ff01 [compiler-rt/profile] Reland mark __llvm_profile_raw_version as hidden
Since libclang_rt.profile is added later in the command line, a
definition of __llvm_profile_raw_version is not included if it is
provided from an earlier object, e.g.  from a shared dependency.

This causes an extra dependence edge where if libA.so depends on libB.so
and both are coverage-instrumented, libA.so uses libB.so's definition of
__llvm_profile_raw_version.  This leads to a runtime link failure if the
libB.so available at runtime does not provide this symbol (but provides
the other dependent symbols).  Such a scenario can occur in Android's
mainline modules.
E.g.:
  ld -o libB.so libclang_rt.profile-x86_64.a
  ld -o libA.so -l B libclang_rt.profile-x86_64.a

libB.so has a global definition of __llvm_profile_raw_version.  libA.so
uses libB.so's definition of __llvm_profile_raw_version.  At runtime,
libB.so may not be coverage-instrumented (i.e. not export
__llvm_profile_raw_version) so runtime linking of libA.so will fail.

Marking this symbol as hidden forces each binary to use the definition
of __llvm_profile_raw_version from libclang_rt.profile.  The visiblity
is unchanged for Apple platforms where its presence is checked by the
TAPI tool.

Reviewed By: MaskRay, phosek, davidxl

Differential Revision: https://reviews.llvm.org/D111759
2021-11-16 11:37:00 -08:00
Pirama Arumuga Nainar ab3d5d0533 Revert "[compiler-rt/profile] Hide __llvm_profile_raw_version"
This reverts commit 69708477be to unblock
instrprof-darwin-exports.c failure on MacOS bots.
2021-10-21 10:56:43 -07:00
Pirama Arumuga Nainar 69708477be [compiler-rt/profile] Hide __llvm_profile_raw_version
Hide __llvm_profile_raw_version so as not to resolve reference from a
dependent shared object.  Since libclang_rt.profile is added later in
the command line, a definition of __llvm_profile_raw_version is not
included if it is provided from an earlier object, e.g.  from a shared
dependency.

This causes an extra dependence edge where if libA.so depends on libB.so
and both are coverage-instrumented, libA.so uses libB.so's definition of
__llvm_profile_raw_version.  This leads to a runtime link failure if the
libB.so available at runtime does not provide this symbol (but provides
the other dependent symbols).  Such a scenario can occur in Android's
mainline modules.
E.g.:
  ld -o libB.so libclang_rt.profile-x86_64.a
  ld -o libA.so -l B libclang_rt.profile-x86_64.a

libB.so has a global definition of __llvm_profile_raw_version.  libA.so
uses libB.so's definition of __llvm_profile_raw_version.  At runtime,
libB.so may not be coverage-instrumented (i.e. not export
__llvm_profile_raw_version) so runtime linking of libA.so will fail.

Marking this symbol as hidden forces each binary to use the definition
of __llvm_profile_raw_version from libclang_rt.profile.

Differential Revision: https://reviews.llvm.org/D111759
2021-10-15 11:56:16 -07:00
Min-Yih Hsu 0f6220ddd6 [profile] Move __llvm_profile_raw_version into a separate file
Similar to the reason behind moving __llvm_profile_filename into a
separate file[1]. When users try to use Full LTO with BFD linker to
generate IR level PGO profile, the __llvm_profile_raw_version variable,
which is used for marking instrumentation level, generated by frontend
would somehow conflict with the weak symbol provided by profiling
runtime.

In most of the cases, BFD linkers will pick profiling runtime's weak symbol
as the real definition and thus generate the incorrect instrumentation
level metadata in the final executables.

Moving __llvm_profile_raw_version into a separate file would make
linkers not seeing the weak symbol in the archive unless the frontend
doesn't generate one.

[1] https://reviews.llvm.org/D34797

Differential Revision: https://reviews.llvm.org/D83967
2020-07-16 16:02:04 -07:00