Hi
Here is my first patches to the Win32 platform.
They compile on the mingw platform.
I haven't test them yet, but I thought it will best to put them in the save, just in case...
/Henrik
Path.cpp (8.5 KB)
SysConfig.cpp (1.3 KB)
Program.cpp.diff (4.25 KB)
Signals.cpp.diff (6.09 KB)
Uh... shouldn't a Win32 port use the Win32 API?
Yes, it should. I haven't reviewed Henrik's change set yet but if it
doesn't look like clean Win32 code then I will create a separate target
named MingW and adjust the configure script accordingly.
On the other hand, no one has submitted any Win32 patches yet, so first
come first served 
Reid.
Henrik,
The patches you submitted will not work (at all) for the Win32 platform
because they (still) use Unix system calls. Win32 doesn't have mkdtemp,
fork, execve, etc. Furthermore in Path.cpp forward slashes are still
used. These need to be changed to back slashes.
So, I'm not familiar with mingw platform. Since you've stated they
compile on your mingw platform, I'm assuming mingw is some kind of Unix
clone like cygwin. That raises for me the issue of whether we really
want to support *another* Unix interface on Windows. We are already
supporting cygwin and Interix.
So, would you consider using cygwin or Interix instead of mingw? If not,
then I will place your patches into a lib/System/MingW directory and you
can provide the implementation there. If you want to go that way you'll
need to make some corrections to your patches. The main one is that
you've replicated the generic Unix code into the Path.cpp file. Instead
of doing that, I would prefer it if you #included it so we don't have
duplicate Unix code all over the place.
Thanks,
Reid.
It isn't Win32 code at all. It depends on Unix emulation.
Oh, all right. I'll take a crack at it. I'm an experienced Windows
programmer (but I was programming Unix before Windows even existed). I
was tempted to volunteer but Henrik beat me to it and anyway I'm not
sure if I can afford to spend the time required to do this.
It's not just System/Win32. To properly build on Windows it is bad form
to use anything other than Microsoft's Visual Studio. Even using
makefiles is frowned upon (well, considering Microsoft's offering of
"nmake"...). And "configure" is right out.
But there are some issues with System I'm going to have to take care of
besides using Win32. There appears to be some Unix assumptions like the
presence of /etc or the HOME environment variable. Neither have any
true equivalent in Windows.
And then there's the gcc front end... gcc cannot be bootstrapped using
Microsoft's compiler or a non-Unix-like environment. It may not be
possible at all to do a proper Windows port of the front end. The
Windows ports of gcc generally pretend they're running on Unix.
Anyway, I'll start and take a closer look at System.
At least I'll be building LLVM on my fast computer
Actually, this is one thing that does not need to be done. Windows is
quite happy using forward slashes in Win32 APIs. Of course, any path
you get /back/ from Windows will have back slashes.
But you do have to take drive letters into consideration...
Also network file paths of the form \\host\share-name\dir1\dir2\file.
Jeff,
These are all reasons why the Win32 port doesn't exist today. LLVM is
heavily influenced and implemented by Unix tools/concepts/facilities.
Since building on Win32 will also be a problem, I think that we should
just target cygwin as our Win32 solution for now and get that to work
really well. I know cygwin is a slow pig, but at least we can get LLVM
to work with it. We also have Interix which is another interesting
approach. However, I don't think Interix has the tool support that we
need to build LLVM, its just a Unix interface for windows machines,
isn't it?
I agree that if/when the time comes to support Win32 natively, it will
be a big job involving configuration, new makefiles and project files,
and all the other Visual studio shebang. I'm personally not up to that
task as my Win32 skills are ancient and I have no interest in updating
them.
So, my $0.02 worth on this is that we ought to just leave the Win32 port
alone for now. Most of us have Unix or cygwin and that works fine. When
LLVM gets nearer to commercialization it will become someone's JOB to
port it to Win32 at which time that will happen fairly rapidly. I'm not
saying "don't do it". If you have the time, by all means, it would be
VERY valuable. However, for now, it would also be valuable to just have
you validate the cygwin build regularly.
Make sense?
Reid.
I don't know anything about Interix.
It may be best to defer a true Win32 port. It's not just the time it
would take to do it, it's the time to keep it up to date as LLVM
evolves. The Win32 port will constantly break, and I don't have the
time to keep fixing it. I've got my own time-consuming projects
That said, the architectural issues should still be addressed. What
does LLVM expect to keep in /etc/llvm and where would it keep it on
Windows? How will it handle the Windows custom of having spaces in file
and directory names? (GNU make hates it.) Why would it need to know
the user's "home" directory? That sort of stuff.
I don't have cygwin or any other Unix emulator on my Windows system, so
I couldn't do validation. I do my Unix programming on Unix
These are all reasons why the Win32 port doesn't exist today. LLVM is
Well, the reason it doesn't exist today is that noone has worked on it.
heavily influenced and implemented by Unix tools/concepts/facilities.
Since building on Win32 will also be a problem, I think that we should
just target cygwin as our Win32 solution for now and get that to work
really well. I know cygwin is a slow pig, but at least we can get LLVM
to work with it. We also have Interix which is another interesting
approach. However, I don't think Interix has the tool support that we
need to build LLVM, its just a Unix interface for windows machines,
isn't it?
I sorta agree, but not entirely. In particular, I think that it's
reasonable for LLVM as a whole to require cygwin. However, I think that
it would be great (and doable) to be able build the LLVM tools WITHOUT
linking to the cygwin DLL or using any of the emulation code. This should
provide fast executables without having to change all of our support
makefiles and other stuff.
I agree that if/when the time comes to support Win32 natively, it will
be a big job involving configuration, new makefiles and project files,
and all the other Visual studio shebang. I'm personally not up to that
task as my Win32 skills are ancient and I have no interest in updating
them.
I really am not sure whether it would make sense to do the full VS project
thing. In particular, it would be hard to maintain. Porting lib/System
to use native win32 sounds like an excellent idea though, and IS quite
useful.
Thoughts?
-Chris
> These are all reasons why the Win32 port doesn't exist today. LLVM is
Well, the reason it doesn't exist today is that noone has worked on it.
> heavily influenced and implemented by Unix tools/concepts/facilities.
> Since building on Win32 will also be a problem, I think that we should
> just target cygwin as our Win32 solution for now and get that to work
> really well. I know cygwin is a slow pig, but at least we can get LLVM
> to work with it. We also have Interix which is another interesting
> approach. However, I don't think Interix has the tool support that we
> need to build LLVM, its just a Unix interface for windows machines,
> isn't it?I sorta agree, but not entirely. In particular, I think that it's
reasonable for LLVM as a whole to require cygwin. However, I think that
it would be great (and doable) to be able build the LLVM tools WITHOUT
linking to the cygwin DLL or using any of the emulation code. This should
provide fast executables without having to change all of our support
makefiles and other stuff.
There's a legal reason to avoid cygwin... Unless you cough up money,
it's GPL--and not LGPL.
> I agree that if/when the time comes to support Win32 natively, it will
> be a big job involving configuration, new makefiles and project files,
> and all the other Visual studio shebang. I'm personally not up to that
> task as my Win32 skills are ancient and I have no interest in updating
> them.I really am not sure whether it would make sense to do the full VS project
thing. In particular, it would be hard to maintain. Porting lib/System
to use native win32 sounds like an excellent idea though, and IS quite
useful.
Well... it wouldn't be the end of the world to use GNU make. /Some/ GNU
software would be required, bison if nothing else. Still would need a
Windows-specific set of makefiles. They could be based on the makefiles
generated by configure.
Thoughts?
-Chris
Yes, I did just have another thought The Win32 port would be
pointless unless it can produce Windows executables, especially GUI
apps. LLVM would have to be able to handle Windows.h and friends, and
some way of converting the assembly files produced by llc into binaries.
Ideally, without using GNU as or ld.
I don't know anything about Interix.
It may be best to defer a true Win32 port. It's not just the time it
would take to do it, it's the time to keep it up to date as LLVM
evolves. The Win32 port will constantly break, and I don't have the
time to keep fixing it. I've got my own time-consuming projects
Actually, I don't expect that the Win32 will constantly break once the
bulk of LLVM is converted over. LLVM needs precious little support from
the operating system. A few fork/exec here, a little mmap there, and
some file/path support. That's about it. It may grow overtime, but if
we're using a lot of the operating system interface (any operating
system interface), we're doing something wrong.
That said, the architectural issues should still be addressed.
I agree. Chris made a good point in that there shouldn't be anything
wrong with using cygwin for the build tools but compiling our libraries
so that they make use of native windows calls rather than requiring the
slow cygwin.dll. That would make our tools work much better on windows
and it would not be terribly difficult to do.
What
does LLVM expect to keep in /etc/llvm and where would it keep it on
Windows?
I expect this would just be in the Windows directory (C:\WINNT or
C:\WINDOWS). It *could* keep the configuration files for llvmc and
anything else that uses configuration files in that directory. However,
the likely place for these would be the llvm installation directory. I
might drop the notion of "special paths" in the sys::Path interface and
just replace it with "FindConfigFile" which would do the right thing on
a given platform.
How will it handle the Windows custom of having spaces in file
and directory names? (GNU make hates it.)
I think this is where we use cygwin which has already been shown to work
with our makefiles.
Why would it need to know the user's "home" directory?
This is to allow the user to override the installed configuration file
settings for llvm. Again, we shouldn't expose the concept of "home
directory". Instead we should expose "FindConfigFile".
I don't have cygwin or any other Unix emulator on my Windows system, so
I couldn't do validation. I do my Unix programming on Unix
Can't blame ya!
Thanks, Jeff.
Reid.
Eww. Come now. C:\Program Files\Low Level Virtual Machine\Configuration
-Brian
Only for global settings. For per-user settings, it would be
C:\Documents and Settings\<user>\Application Data\Low Level Virtual Machine\Configuration
and as Application Data is a hidden directory, we can protect the
integrity of the configuration settings from the unwashed masses. So,
am I joking or am I serious
Of course, there's always the registry...
The breakage will come from stuff like new files being added. The UNIX
makefiles are updated, but the VS project files (or even Windows
makefiles) are not. Or C++ code is written that Microsoft's compiler
objects to.
At least you're not using the native compilers on the propriety UNIXes.
Trust me, that is a wise decision.
Actually, I don't expect that the Win32 will constantly break once the
bulk of LLVM is converted over. LLVM needs precious little support from
the operating system. A few fork/exec here, a little mmap there, and
some file/path support. That's about it. It may grow overtime, but if
we're using a lot of the operating system interface (any operating
system interface), we're doing something wrong.
I'm the last person who can raise his hand and speak about the LLVM project but... I feel you are totally right.
IMHO there's a big difference between aiming to port the whole framework to Windows and porting only the very-core-stuff (TM;)
Porting the using-the-jit example, have to be trivial in the sense that you must be able to use the core-stuff in such an easy way, apart from platform differences.
MinGW is a more radical (and efficient) port of the gnu compiler to win32. It does not require any cygwin.dll and try to rely less on emulation. It's distributed with a minimal bash support and common *nix tools. Actually I feel that is probably more difficoult to adapt LLVM to it, but not SO different to the cygwing port. Summa summarum it has the advantage of producing standalone executable without external dependencies.
I agree. Chris made a good point in that there shouldn't be anything
wrong with using cygwin for the build tools but compiling our libraries
so that they make use of native windows calls rather than requiring the
slow cygwin.dll. That would make our tools work much better on windows
and it would not be terribly difficult to do.
I think that MinGW is a better alternative to cygwin on windows....
I think this is where we use cygwin which has already been shown to work
with our makefiles.
Also with MinGW you have all the build tools chain... but alas, someone must try it 
That told, building the LLVM with the microsoft compiler is another matter. I'm interested in building the backend, not the frontend tools (hoping to skip a lot of problem related to signal-paths-and-portability-mess), because I want to play with the 'compiler-infrastructure'. Actually the MS C compiler is a GOOD compiler, very compliant and efficient, and has the BIG advantage that is compiles with the defacto-standard MS C runtime...
I'm very busy in these days... but I hope to send other VC patches soon.
On further reflection, I think we need to abstract the operation of
throwing a formatted OS error message. This is done in many places, and
the Windows way of doing it differs substantially from Unix. Basically
take the ThrowError function and turn it into Process::ThrowOSError or
something like that.
Here are some more... and that takes care of the easy ones.
Path I'll wait on until you finish updating it.
Signals is a problem... It appears to be doing two tasks. First, it
prints a stack trace when something like a seg fault occurs. Second, it
makes sure a set of files and directories are deleted on an abnormal
exit.
The first is no problem. It won't even be necessary to fork off a
separate program, so long as Microsoft-format symbol tables are present
(and if there aren't... well... you'll just get a bunch of hexadecimal
addresses).
The other is a problem. It is not possible to delete open files on
Windows, and the odds are these files will be open because... well...
things crashed before there was a chance to clean things up.
Even for the files which aren't open and so can be deleted, you wouldn't
necessarily want to delete them at this point. After this handler
executes, a dialog box pops up asking if you want to start the debugger.
It might be a good idea to keep these files around as the program
technically is still executing while it's being debugged.
There is a Windows-centric solution to this: open the files with the
delete-on-close flag. The implicit closing of all open files at process
termination--normal or abnormal, or even post debugging--will trigger
the deletion. How to take advantage of this is unfortunately far from
obvious.
Memory.cpp (1.94 KB)
Process.cpp (1.43 KB)
Program.cpp (4.55 KB)
SysConfig.cpp (1.06 KB)
Thanks, Jeff. I'll take a look at these later tonight and get them into
CVS.
Reid.
Jeff/Henrik/Others,
Thanks for contributing your patches. I really appreciate it.
I've committed the changes that Jeff submitted for lib/System/Win32. I
made some changes as I did. The departures are these:
* I created a "Win32.h" header which includes our config header,
windows.h and defines an inline ThrowError function that was
duplicated in several modules. This is analagous to the Unix.h file in
the lib/System/Unix directory.
* I modified the SysConfig.cpp implementation to only get the page size
once from the operating system and cache it in a static variable so
that there isn't a huge penality every time this value is fetched.
Henrik, I couldn't use your patches because they were malformed. Make
sure that your email software doesn't mess with your attachments. It
seems to be wrapping lines on you which messed up first character being
+ or -. Also, please always submit patches in unified diff format (diff
-u). If it helps, send patches in winzip or tar.gz format which
shouldn't get modified by your email software.
From here on out, I'd appreciate it if you'd submit patches to the
current CVS version. Just makes life much easier this end.
Thanks to you both.
Reid.