llvm-svn: 172358

Sooooo many of these had incorrect or strange main module includes.
I have manually inspected all of these, and fixed the main module
include to be the nearest plausible thing I could find. If you own or
care about any of these source files, I encourage you to take some time
and check that these edits were sensible. I can't have broken anything
(I strictly added headers, and reordered them, never removed), but they
may not be the headers you'd really like to identify as containing the
API being implemented.

Many forward declarations and missing includes were added to a header
files to allow them to parse cleanly when included first. The main
module rule does in fact have its merits. =]

llvm-svn: 169131

llvm-svn: 163131

llvm-svn: 138260

llvm-svn: 137844

Use DynamicLibrary instances as a way to get symbols from a specific library. Preparation for upcoming (preliminary) support for plugins for the static analyzer.

llvm-svn: 137791

llvm-svn: 121119

llvm-svn: 120298

Use thread-safe statics to avoid a static constructor here.  This isn't thread-safe on MSVC, but we don't
support threaded LLVM there anyways.

llvm-svn: 119718

llvm-svn: 118463

cygwin when built with ENABLE_SHARED=1.  Patch by NAKAMURA Takumi!

llvm-svn: 111231

llvm-svn: 101376

llvm-svn: 100895

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().

llvm-svn: 98243

DynamicLibrary::SearchForAddressOfSymbol refer to declarations in the
global namespace.

llvm-svn: 92023

llvm-svn: 92021

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.

llvm-svn: 92020

llvm-svn: 85074

llvm-svn: 80589

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.

llvm-svn: 74927

llvm-svn: 74926

llvm-svn: 74924

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?

llvm-svn: 74188

llvm-svn: 63269

Patch by Samuel Tardieu.

llvm-svn: 57291

llvm-svn: 53385

llvm-svn: 50695

Thanks Daniel Dunbar!

llvm-svn: 48340

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!

llvm-svn: 48270

llvm-svn: 47479

llvm-svn: 47065

llvm-svn: 45781

llvm-svn: 45418

llvm-svn: 44528

this out.

llvm-svn: 42448

llvm-svn: 40616

llvm-svn: 33746

llvm-svn: 33375

needed for output to be generated. On Linux these are both global vars and
macro definitions so we have to special case Linux.

llvm-svn: 33374

llvm-svn: 33373