A first!

I compiled a simple "hello world!" C program on FreeBSD, transfered the a.out.bc file to Windows, and executed it with an lli.exe that I built with Visual Studio. It worked!

Great News! Thanks for sharing it!

Reid.

Great news, but note that not all bytecode files are so portable. :slight_smile:

Turns out it wasn't using the JIT. It was running the interpreter. The X86 stuff wasn't being linked in. Alas, once I "fixed" that, it stopped working. The JIT couldn't resolve the symbol "printf" and failed. But the interpreter could resolve it.

Misha Brukman wrote:

The interpreter has some hacks for dealing with common functions like
"printf" :slight_smile: We need to get the Win32 equivalent of dlsym() going for
the JIT to work on Windows.

Misha,

The "equivalent of dlsym" should be working just fine. Its called ltdl
(libtool dynamic library) and is part of lib/System. Its interface is
the DynamicLibrary class. The interpreter has already been modified to
use this facility.

So, if this is broken on windows, I'd like to know how, or why.

Jeff, can you provide a test case that we can use to reproduce this
problem? Looks like I'm finally going to force myself into a windows
build (i.e. cough up the money for VC++ 7.1).

Reid.

Another and cheaper option could be to buy an used vc++ 7.1 development package.

Henrik.

----Original Message Follows----

The interpreter still resolves printf using a hack. It does try to use DynamicLibrary to find it, but fails. DynamicLibrary on Windows only searches the main program executable for symbols, lli.exe in this case. As the C/C++ runtime is in a DLL, it won't find printf in lli.exe. It ought to then search the runtime DLL, the name of which depends on how the binaries are built, but it doesn't. It should probably enumerate and search all DLLs present in the process, including the system DLLs so that a program can use the Win32 API, but there's no code to do that in ltdl.c.

This code needs to be added, but I'm not sure where. win32/DynamicLibrary.cpp is not the place, as it is never compiled, just as none of */DynamicLibrary.cpp are compiled. I still don't know why these files exist. But ltdl.c doesn't feel right either, as it's GNU software. The main DynamicLibrary.cpp is supposed to be platform independent, so that doesn't seem appropriate either, nonetheless seems to be the best bet.

Reid Spencer wrote:

There's a problem with the license for ltdl.c when building with VC++. It is under the LGPL, with a special exception:

As a special exception to the GNU Lesser General Public License,
if you distribute this file as part of a program or library that
is built using GNU libtool, you may include it under the same
distribution terms that you use for the rest of that program.

The problem is, when built with Visual Studio, libtool is not used. Therefore the LGPL exception does not apply, thereby infecting all of LLVM with the LGPL.

Jeff Cohen wrote:

The interpreter still resolves printf using a hack. It does try to use
DynamicLibrary to find it, but fails. DynamicLibrary on Windows only
searches the main program executable for symbols, lli.exe in this case.
As the C/C++ runtime is in a DLL, it won't find printf in lli.exe. It
ought to then search the runtime DLL, the name of which depends on how
the binaries are built, but it doesn't. It should probably enumerate
and search all DLLs present in the process, including the system DLLs so
that a program can use the Win32 API, but there's no code to do that in
ltdl.c.

Okay, this is *supposed* to be happening automatically. The same issue
will happen on unix with shared objects loaded dynamically. So, either
DynamicLibrary.cpp is using ltdl wrong or there's a win-specific bug in
ltdl.cpp (doubt it, this code's been around for a while).

This code needs to be added, but I'm not sure where.
win32/DynamicLibrary.cpp is not the place, as it is never compiled, just
as none of */DynamicLibrary.cpp are compiled.

Yeah, that was the original implementation. I just deleted them all.
Sorry for the confusion, I haven't gotten to cleanning up lib/System
yet. That will probably happen next week.

I still don't know why these files exist.

They shouldn't :slight_smile:

But ltdl.c doesn't feel right either, as it's GNU
software. The main DynamicLibrary.cpp is supposed to be platform
independent, so that doesn't seem appropriate either, nonetheless seems
to be the best bet.

DynamicLibrary.cpp is "supposed" to be platform agnostic, but we make an
exception in its special case. It already has Darwin specific hacks in
it for certain symbols. We need to figure out why the DDLs aren't
getting searched and (hopefully) fix our use of ltdl in DynamicLibrary
so that they are searched. If you want to take a crack at it, feel free,
I have some other issues to work on. If you'd rather me do it, let me
know so I don't wait for you :slight_smile:

Reid.

Ugh. Yeah, the Unix platforms are covered but not when building with
VC++. Not sure what to do about that. We'll have to sort this out when
the UIUC crew comes back from vacation/holidays. Until then, please
don't distribute any LLVM's built with VC++ unless you also comply with
the LGPL.

I've been thinking about converting our makefiles so that they could run
with the VC++ toolset. It would then be possible to create VC++
compatible DLLs and executables but via cygwin/make running to build it.
Not sure if that's a reasonable thing nor if we could still use libtool
in such a scenario.

Thanks,

Reid.

I have committed a change so that ltdl is no longer used for VC++ builds.

Morten, you can start breathing again :slight_smile:

As a side effect, the JIT can now resolve "printf" on Windows (and presumably anything else to be found in a DLL).

Jeff Cohen wrote: