included when using global symbols to ask the linker for the addresses of
various functions. One of the symbols was actually getting declared by a
header included in DynamicLibrary.cpp, which conflicted with the "extern void*"
declaration in SearchForAddressOfSpecialSymbol().
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@98243 91177308-0d34-0410-b5e6-96231b3b80d8
DynamicLibrary::SearchForAddressOfSymbol and force them to have "C"
linkage.
Interestingly, GCC treats the block-scoped "extern" declarations we
previously had as if they were extern "C" declarations (or, at least,
were in the global namespace), so that GCC bug papered over this LLVM
bug. Clang and EDG get the linkage correct; this new variant seems to
work for both GCC and Clang.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@92020 91177308-0d34-0410-b5e6-96231b3b80d8
This fixes PR4512 and eliminating static ctors is always good. Losing
thread safety is unfortunate, but the code is just incredibly poorly
designed.
If someone is interested, the "right" solution is to split
DynamicLibrary.cpp into two separate pieces: a stateless piece in
libsystem, and a simple support file in libsupport that has the
"state" (e.g. AddSymbol) in managed static objects.
Doing this would both fix memory leaks we already have, as well as make
the code thread safe again. it would also make sense to move all the
unix specific code in System/DynamicLibrary.cpp into
System/Unix/DynamicLibrary.inc.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@74927 91177308-0d34-0410-b5e6-96231b3b80d8
I did my best at implementing this for Win32, but I don't have a way to test it.
Can someone with access to a Win32 machine test/fix this?
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@74188 91177308-0d34-0410-b5e6-96231b3b80d8
LoadLibraryPermanently. The current code modifies the value of a pointer
that is passed by value, so the caller never gets the message.
Patch by Julien Lerouge!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@48270 91177308-0d34-0410-b5e6-96231b3b80d8
needed for output to be generated. On Linux these are both global vars and
macro definitions so we have to special case Linux.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@33374 91177308-0d34-0410-b5e6-96231b3b80d8
Final commit for this bug. This removes the last EH holdouts in LLVM
and turns off exception support by using the -fno-exceptions option. This
leads to the following reduction in library and executable sizes:
DEBUG BUILD RELEASE BUILD
before after delta before after delta
lib 162,328K 157,616K 4,712 17,864K 16,416K 1,448K
bin 571,444K 557,156K 14,288 63,296K 56,996K 6,300K
Debug Improvement: 19,000K (2.59%)
Release Improvement: 7,748K (9.55%)
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@29882 91177308-0d34-0410-b5e6-96231b3b80d8
Put the rest of lib/System into LinkAllVMCore.h. This makes all of
lib/System available to programs that #include LinkALlVMCore.h so that
loadable modules linked into those programs can depend on all of lib/System
being available.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@29288 91177308-0d34-0410-b5e6-96231b3b80d8
of being unable to search for symbols in an EXE. It will also allow other
existing hacks to be improved.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@25805 91177308-0d34-0410-b5e6-96231b3b80d8
gdb debugger doesn't get confused on which file it is reading (the one in
lib/System or the one in lib/System/{Win32,Unix})
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@19426 91177308-0d34-0410-b5e6-96231b3b80d8
library (shared library/shared object) whose symbols can be looked up
dynamically. Used for plug-ins.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@17940 91177308-0d34-0410-b5e6-96231b3b80d8
