[Bug other/89856] `ld: warning: direct access to global weak symbol means the weak symbol cannot be overridden at runtime` using LTO with optimization and -fprofile-generate
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89856 --- Comment #6 from Oliver Rosten --- If you're sure. The only thing which gives me pause for thought is that the problem I see with source_location only occurs when I also see ld: warning: direct access to global weak symbol means the weak symbol cannot be overridden at runtime This is the only time I've ever come across this in my code...
[Bug other/89856] `ld: warning: direct access to global weak symbol means the weak symbol cannot be overridden at runtime` using LTO with optimization and -fprofile-generate
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89856 --- Comment #5 from Andrew Pinski --- (In reply to Oliver Rosten from comment #4) > I think I've come across a case where this is symptomatic of a serious > problem -see https://github.com/ojrosten/SourceLoc That seems totally unrelated to this issue, please file as a seperate issue.
[Bug other/89856] `ld: warning: direct access to global weak symbol means the weak symbol cannot be overridden at runtime` using LTO with optimization and -fprofile-generate
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89856
Oliver Rosten changed:
What|Removed |Added
CC||oliver.rosten at googlemail
dot co
||m
--- Comment #4 from Oliver Rosten ---
I think I've come across a case where this is symptomatic of a serious problem
-see https://github.com/ojrosten/SourceLoc
The project comprises three files in the Test directory:
Main.cpp
Test.cpp
Test.hpp
Both the cpps depend on the hpp. The latter contains an unused variable
inline const std::string foo{};
The presence of this seems to cause:
1. The ld warning related to this bug report;
2. std::source_location::current() to misbehave: building and running causes
the path to Main.cpp to be output twice, whereas it should just be printed
once, with the path to Test.cpp appearing second.
Any of the following cures both of the problems:
1. Removing foo;
2. Removing inline;
3. Replacing const with constexpr
In the much more complex project where I first encountered this, I reliably got
a segmentation fault. I was able to cure this by removing inline in a handful
of places.
[Bug other/89856] `ld: warning: direct access to global weak symbol means the weak symbol cannot be overridden at runtime` using LTO with optimization and -fprofile-generate
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89856 Richard Biener changed: What|Removed |Added Target Milestone|7.5 |---
[Bug other/89856] `ld: warning: direct access to global weak symbol means the weak symbol cannot be overridden at runtime` using LTO with optimization and -fprofile-generate
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89856 --- Comment #3 from Daniel Vollmer --- These linker warnings then also seem to result in actual address-sanitizer errors (which may or may not be spurious): (Output not from the provided example, but the shown _GLOBAL__sub_I_00099_1_CommunicationBuffersBase.cpp refers to a templated method with a static local variable like the BroadcastFromMaster example. Process 40885 launched: '/usr/local/Cellar/python@2/2.7.16/Frameworks/Python.framework/Versions/2.7/Resources/Python.app/Contents/MacOS/Python' (x86_64) ==40885==The following global variable is not properly aligned. ==40885==This may happen if another global with the same name ==40885==resides in another non-instrumented module. ==40885==Or the global comes from a C file built w/o -fno-common. ==40885==In either case this is likely an ODR violation bug, ==40885==but AddressSanitizer can not provide more details. = ==40885==ERROR: AddressSanitizer: odr-violation (0x00050083): Process 40885 stopped * thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x90186) frame #0: 0x0001000e7169 libasan.4.dylib`__asan::PrintGlobalLocation(__sanitizer::InternalScopedString*, __asan_global const&) + 25 libasan.4.dylib`__asan::PrintGlobalLocation: -> 0x1000e7169 <+25>: movq (%rax), %rdx 0x1000e716c <+28>: testq %rdx, %rdx 0x1000e716f <+31>: je 0x1000e71e0 ; <+144> 0x1000e7171 <+33>: leaq 0x79838(%rip), %rsi ; "%s" Target 0: (Python) stopped. (lldb) bt * thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x90186) * frame #0: 0x0001000e7169 libasan.4.dylib`__asan::PrintGlobalLocation(__sanitizer::InternalScopedString*, __asan_global const&) + 25 frame #1: 0x0001000df8bf libasan.4.dylib`__asan::ErrorODRViolation::Print() + 191 frame #2: 0x00010013ba9c libasan.4.dylib`__asan::ReportODRViolation(__asan_global const*, unsigned int, __asan_global const*, unsigned int) + 1484 frame #3: 0x0001000e65ed libasan.4.dylib`__asan_register_globals.part.11 + 1469 frame #4: 0x00010ae9df96 libFlis.dylib`_GLOBAL__sub_I_00099_1_CommunicationBuffersBase.cpp + 31 frame #5: 0x00010001c592 dyld`ImageLoaderMachO::doModInitFunctions(ImageLoader::LinkContext const&) + 506 frame #6: 0x00010001c798 dyld`ImageLoaderMachO::doInitialization(ImageLoader::LinkContext const&) + 40 frame #7: 0x000100017bea dyld`ImageLoader::recursiveInitialization(ImageLoader::LinkContext const&, unsigned int, char const*, ImageLoader::InitializerTimingList&, ImageLoader::UninitedUpwards&) + 362 frame #8: 0x000100017b80 dyld`ImageLoader::recursiveInitialization(ImageLoader::LinkContext const&, unsigned int, char const*, ImageLoader::InitializerTimingList&, ImageLoader::UninitedUpwards&) + 256 frame #9: 0x000100017b80 dyld`ImageLoader::recursiveInitialization(ImageLoader::LinkContext const&, unsigned int, char const*, ImageLoader::InitializerTimingList&, ImageLoader::UninitedUpwards&) + 256 frame #10: 0x000100016d73 dyld`ImageLoader::processInitializers(ImageLoader::LinkContext const&, unsigned int, ImageLoader::InitializerTimingList&, ImageLoader::UninitedUpwards&) + 133 frame #11: 0x000100016e05 dyld`ImageLoader::runInitializers(ImageLoader::LinkContext const&, ImageLoader::InitializerTimingList&) + 73 frame #12: 0x00019cb2 dyld`dyld::runInitializers(ImageLoader*) + 82 frame #13: 0x0001000133dc dyld`dlopen_internal + 607 frame #14: 0x7fff713dbd43 libdyld.dylib`dlopen + 200 frame #15: 0x0001000f4f9b libasan.4.dylib`wrap_dlopen.part.109 + 75 frame #16: 0x000100f1fef7 Python`_PyImport_GetDynLoadFunc + 306 frame #17: 0x000100f0b43a Python`_PyImport_LoadDynamicModule + 89 frame #18: 0x000100f0a209 Python`import_submodule + 273
[Bug other/89856] `ld: warning: direct access to global weak symbol means the weak symbol cannot be overridden at runtime` using LTO with optimization and -fprofile-generate
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89856
--- Comment #2 from Daniel Vollmer ---
I'm seeing the same warning in a similar context when using the
address-sanitizer, e.g.
> cat lib.cpp
#include
#include
inline const std::string ()
{
static const std::string str = "abc";
return str;
}
void func2()
{
const auto str = func1();
std::cout << str << std::endl;
}
> g++-7 -fsanitize=address -std=c++14 -shared lib.cpp -o lib.dylib
ld: warning: direct access in function '__GLOBAL__sub_D_00099_0_lib.cpp' from
file '/var/folders/02/yl3m8d4d0397mk6dxn6dpcqwgp/T//ccEl2k3C.o' to global
weak symbol 'guard variable for func1[abi:cxx11]()::str' from file
'/var/folders/02/yl3m8d4d0397mk6dxn6dpcqwgp/T//ccEl2k3C.o' means the weak
symbol cannot be overridden at runtime. This was likely caused by different
translation units being compiled with different visibility settings.
ld: warning: direct access in function '__GLOBAL__sub_I_00099_1_lib.cpp' from
file '/var/folders/02/yl3m8d4d0397mk6dxn6dpcqwgp/T//ccEl2k3C.o' to global
weak symbol 'guard variable for func1[abi:cxx11]()::str' from file
'/var/folders/02/yl3m8d4d0397mk6dxn6dpcqwgp/T//ccEl2k3C.o' means the weak
symbol cannot be overridden at runtime. This was likely caused by different
translation units being compiled with different visibility settings.
(Same with g++-9.1)
[Bug other/89856] `ld: warning: direct access to global weak symbol means the weak symbol cannot be overridden at runtime` using LTO with optimization and -fprofile-generate
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89856 Iain Sandoe changed: What|Removed |Added Target||*-*-darwin* Status|UNCONFIRMED |NEW Last reconfirmed||2019-03-27 CC||iains at gcc dot gnu.org Target Milestone|--- |7.5 Ever confirmed|0 |1 Known to fail||7.4.1, 8.3.1
[Bug other/89856] `ld: warning: direct access to global weak symbol means the weak symbol cannot be overridden at runtime` using LTO with optimization and -fprofile-generate
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89856 --- Comment #1 from Daniel Vollmer --- Initial analysis from Iain Sandoe > OK (initial analysis). what we have is > > __ZGVZ19BroadcastFromMasterImEvPT_mE4bufs: > .space 8 > > > LPX0: > > > and then a reference to LPX0 in __GLOBAL__sub_I_65535_0_test.cpp. > > So ld64 breaks the code and data into "atoms" where each atom begins with a > linker-visible symbol. > > What it's saying is that the data pointed to by LPX0 is in the atom named > __ZGVZ19BroadcastFromMasterImEvPT_mE4bufs (because LPX0 is not visible to > the linker). > > right now, not sure if it's really a potential issue or just more linker > warning noise - need to look at it fresh with plenty of coffee. FWIW, Linux > generates pretty much identical code, but (of course) the BFD linker has > different behaviour from Darwin's ld64.
