On Wed, 2005-02-16 at 19:52, Aaron Gray wrote:> Hi Reid,
>
> I'll send a complete report tommorow, its getting late.
Great!
>
> It looks like there is alot of work to do to get the MS VC version in line
> with the Unix release. I am very willing to help out with porting.
Yes, there are several well known issues remaining. The bugpoint tool
and the debugger use unix specific function calls. Unfortunately,
replacing them means doing a little re-design work. In general I've been
responsible for overall portability but Jeff Cohen has done the bulk of
the legwork for VC++ and Win32. Henrik Bach has also got things running
under mingw compiler. Any expertise/help you can provide in these areas
would be very welcome (patches accepted!) as we are striving to get all
of LLVM running under windows (natively and with Cygwin).
>
> The tests and regression tests look a biggy maybe they would be better done
> on the command line using make rather than separate Visual Studio projects.
I'd talk to Jeff Cohen about that. We use dejagnu and a pretty simple
command line interpreter (test/TestRunner.sh) to invoke the feature and
regression tests. The llvm-test project is a whole other thing.
>
> As I say I am willing to help out porting so maybe to avoid duplication if
> someone takes charge and points to what needs doing then it would be easier
> than me just going blind at the problem.
Sure, here's a few tips:
1. lib/System (include/llvm/System) is the operating system abstraction
layer. It provides only those things that LLVM needs so its not a
complete abstraction layer. Its currently divided into two camps: Unixes
and Win32. It might get subdivided further if we port to other operating
system types (OS/390, VMS, RTOS, etc.). The basic idea is that the
interfaces provided in include/llvm/System get implemented with the same
semantics on all platforms.
2. API documentation here: http://illuvium.com/docs/doxygen/. More
general documentation is at http://llvm.cs.uiuc.edu/docs/. In
particular, you should read the Getting Started document if you haven't
already.
3. The win32 directory (at top level) contains the vcproj files for
building with the MS compiler. No doubt you've already discovered these.
4. The generalization of debugger inferior processes hasn't been done
yet because the underlying operating system mechanisms are so different.
This is what is holding up the llvm-db tool from working on win32. We
need to factor out the platform-specific portions and make lib/System
interfaces for them and then make it portable.
5. The use of fork (without execve) in the bugpoint tool is what
prevents that tool from working on win32. We need to abstract out the
notion of forking/parallelism in the same process and fake it with
threads or something in win32. Either that or redesign bugpoint a
little.
6. Not much has been done with the test suites on win32. There are 3
test suites: llvm/test/Features, llvm/test/Regression, and the llvm-test
project (separate CVS repository). Features and Regressions are
small/light/fast tests that cover basic functionality and problems we've
previously run into. I'm currently working on getting the llvm-test
suite to pass on Cygwin. I don't know if anyone's looked into getting
these tests to run with win32 native executables. The testing harness is
pretty unix-centric but it might be possible to cajole them into running
under Cygwin but using win32 built executables (as opposed to Cygwin
executables).
7. Pretty much everything else is already portable.
I'd talk to Jeff Cohen about his efforts with win32 as he's been the
primary developer on that.
Thanks, Aaron.
Reid.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20050216/60703938/attachment.sig>