llvm dev - May 2012 - [LLVMdev] Windows question: Dozens of linker warnings and errors

Thanks for the quick reply.  I had a feeling that it was due to missing
Windows support in clang++ and LLVM.

"""
This is due to clang not understanding force_inline. These functions
are defined in a header included from Windows.h, so it ends up getting
a definition everywhere it is included.
"""

How much work would it take to add support for force_inline?  Are there any
plans for when/if it will be supported?  I don't know anything about
force_inline, but I guess supporting it is a relatively simple matter.
 After all, isn't a forced_inline construct similar to an inlined template
method?  In the old MS-OMF days, we'd start talking about COMDATs and stuff
like that, but I don't know how it is done nowadays.

"""
The rest of the issues are due to clang not supporting the Microsoft
C++ ABI yet. To use clang on Windows for C++ code you will need to use
it with MinGW as it provides libraries that use the GNU C++ ABI.

"""
I guess this is quite a mouthful, but when do you roughly expect the
Microsoft C++ ABI to be supported?  v4.0 or later?  Is there anything not
too overwhelming and/or complex that I can do to speed up this process?

I am asking these questions because I see myself as a wannabe client of the
LLVM tools - I don't know much about code generation and I don't really
want to know much about it, all I want to do is to make my own production
language using LLVM as the portable (also to Windows/M$) backend.  My hope
is that LLVM can save me the hassles of meddling around with assembler and
so on, as I'd much rather spend my energy on my language.  But if the
Windows support is broken, partial beyond use, or never to be finished up,
I cannot use LLVM.  Then I'd have spend my energy on writing my own simple
code generator, which would never generate code of a quality anywhere near
LLVM.  Or, I could go ahead and do my own silly backend and then check up
on LLVM in a couple of years, to see if the Windows support was matured.

By the way, I do have a background in linkers and compilers for Windows
platforms, so if I can help with anything, I'll be glad to do so.  Just
don't expect me to work miracles from day one because it has been almost 15
years since I last worked with compilers and linkers.

Perhaps I can contribute in the field of Windows support?   I once wrote a
librarian for OMF (the ancient object file format used under DOS) and COFF.
 I could probably add support for COFF archives to llvm-ar, if need be.
 And stuff like that.


Sincerely,
Mikael
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20120524/22652b78/attachment.html>

On Wed, May 23, 2012 at 6:12 PM, Mikael Lyngvig <mikael at lyngvig.org>
wrote:
> Thanks for the quick reply.  I had a feeling that it was due to missing
> Windows support in clang++ and LLVM.
>
> """
> This is due to clang not understanding force_inline. These functions
> are defined in a header included from Windows.h, so it ends up getting
> a definition everywhere it is included.
> """
>
> How much work would it take to add support for force_inline?  Are there any
> plans for when/if it will be supported?  I don't know anything about
> force_inline, but I guess supporting it is a relatively simple matter.
>  After all, isn't a forced_inline construct similar to an inlined
template
> method?  In the old MS-OMF days, we'd start talking about COMDATs and
stuff
> like that, but I don't know how it is done nowadays.
It should be trivial. Clang already parses it. It just needs to get
hooked up to the attribute system, as we already support the gnu
version of it (I believe alwaysinline).
> """
> The rest of the issues are due to clang not supporting the Microsoft
> C++ ABI yet. To use clang on Windows for C++ code you will need to use
> it with MinGW as it provides libraries that use the GNU C++ ABI.
>
> """
> I guess this is quite a mouthful, but when do you roughly expect the
> Microsoft C++ ABI to be supported?  v4.0 or later?  Is there anything not
> too overwhelming and/or complex that I can do to speed up this process?
People are actively working on it, but I have no idea when it will be ready.
> I am asking these questions because I see myself as a wannabe client of the
> LLVM tools - I don't know much about code generation and I don't
really want
> to know much about it, all I want to do is to make my own production
> language using LLVM as the portable (also to Windows/M$) backend.  My hope
> is that LLVM can save me the hassles of meddling around with assembler and
> so on, as I'd much rather spend my energy on my language.  But if the
> Windows support is broken, partial beyond use, or never to be finished up,
I
> cannot use LLVM.  Then I'd have spend my energy on writing my own
simple
> code generator, which would never generate code of a quality anywhere near
> LLVM.  Or, I could go ahead and do my own silly backend and then check up
on
> LLVM in a couple of years, to see if the Windows support was matured.
LLVM already supports Windows quite well. The issue is clang and the
MS C++ ABI. If you are writing your own language that does not need to
interact with the C++ ABI then everything will be fine.
> By the way, I do have a background in linkers and compilers for Windows
> platforms, so if I can help with anything, I'll be glad to do so.  Just
> don't expect me to work miracles from day one because it has been
almost 15
> years since I last worked with compilers and linkers.
>
> Perhaps I can contribute in the field of Windows support?   I once wrote a
> librarian for OMF (the ancient object file format used under DOS) and COFF.
>  I could probably add support for COFF archives to llvm-ar, if need be.
 And
> stuff like that.
Increasing support for Windows across LLVM is a welcome addition. My
main area on LLVM currently is actually binary tools, and adding
object file support to llvm-ar is one of the items on my list. You may
also be interested in the lld linker project (lld.llvm.org).
> Sincerely,
> Mikael
- Michael Spencer

On 05/24/2012 03:37 AM, Michael Spencer wrote:
> LLVM already supports Windows quite well. The issue is clang and the
> MS C++ ABI. If you are writing your own language that does not need to
> interact with the C++ ABI then everything will be fine.
I can confirm this. Even if you do need to interface to C/C++, clang
works fine for that as long as you stick to the mingw libraries instead
of msvc. There are already a number of full-blown LLVM-based language
projects by 3rd parties you can take a look at, see
http://llvm.org/releases/3.1/docs/ReleaseNotes.html#externalproj.

Speaking about my own project (http://pure-lang.googlecode.com/), we've
had that up and running on Linux, *BSD, OS X and Windows at least since
the days of LLVM 2.5, using first llvm-gcc and then clang as an
LLVM-capable C/C++ compiler for inlining C/C++ in Pure. I vaguely recall
some issues with clang 3.0 on Windows due to hardcoded paths. But clang
2.9 has been working great on Windows for me and other Pure users,
hopefully 3.1 will be the same.

Albert

-- 
Dr. Albert Gr"af
Dept. of Music-Informatics, University of Mainz, Germany
Email:  Dr.Graef at t-online.de, ag at muwiinfa.geschichte.uni-mainz.de
WWW:    http://www.musikinformatik.uni-mainz.de/ag

"""
Increasing support for Windows across LLVM is a welcome addition. My
main area on LLVM currently is actually binary tools, and adding
object file support to llvm-ar is one of the items on my list. You may
also be interested in the lld linker project (lld.llvm.org).
"""

I am looking at the llvm-ar and Archive.cpp source code right now.  It
seems it to only supports ELF archives (and COFF, etc. object files) at the
time?  I guess we'll have to refactor so as to introduce a polymorphic
class hierarchy.  Or, how do you do it in LLVM?  Not that I am about to
code anything; I won't touch anything until we have clearly decided what I
should and should not do and until you give me a "go!".  I don't
even know
if you really want me to look at implementing COFF archive support or not.
 After all, it is on your to-do list, not mine :-)  My plan now is to spend
some days studying the llvm-ar and lib/Object files and get to know them
well enough that I know what should and should not be done.

Also, I suppose you already have this:

    http://msdn.microsoft.com/library/windows/hardware/gg463125 (Microsoft
PE Common Object File Format Specification v8.0)

If not, you're going to need it sooner or later.

Also, I have to warn that my C++ is a bit rusty.  I have coded in C++ since
1990, but I have hardly used it the past 10 years so there is some catching
up to do.  For instance, I just ran into the "explicit" keyword and
had to
do a Google search to find out what that meant.  Also, I'm only vaguely
familiar with the STL.  I'm not unfamiliar with OOP, etc., it is just that
I have been using Python and C# for the past decade.


Cheers,
Mikael
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20120526/37f348b9/attachment.html>