tree 505ef4dc246d7786103db779a172844154bb4552
parent 3a1c94f5d3e9495eebe4954114e135a4ec167d33
author Leonard Chan <leonardchan@google.com> 1713903843 +0000
committer Leonard Chan <leonardchan@google.com> 1714070150 +0000

[glog] Add [[clang::lto_visibility_public]]

With whole program devirtualization enabled, we see a call to
streambuf::underflow incorrectly devirtualized to
basic_streambuf::underflow() when it should instead not be devirtualized
and a vtable call will result in the correct call to
basic_filebuf::underflow. WPD is doing this because we are statically
linking in the definitions and vtables for these classes from libc++.a.
This is an incorrect use of WPD because the definitions of these classes
are outside the LTO unit being linked, so when we attempt to devirt the
calls, the only visible class in the LTO unit is LogStreamBuf thus WPD
assumes the only possible call that can be made for the call to
underflow is the definition from LogStreamBuf, which directly inherits
from std:streambug (aka basic_streambuf).

The correct way to use WPD would be to compile all relevant TUs with
-flto, but we aren't currently able to do that with the llvm runtimes.
Ideally, FatLTO will help with this since we'd ship both bitcode and
objcode, but that's some ways away. For now, what we can do, without
explicitly making the class have default ELF visibility is to make
LogStreamBuf have public LTO visibility. This means the this class is
accessible outside the LTO unit and can have child classes and cannot be
a candidate for devirting.

Bug: 42075686
Change-Id: I520345493e7047e751c2030081ab42bad95566d3
Reviewed-on: https://fuchsia-review.googlesource.com/c/third_party/glog/+/1035172
Reviewed-by: Cameron Dale <camrdale@google.com>