[llvm-dev] llvm-mc & Microsoft's MASM

[Zachary Turner via llvm-dev]

Yes, that is correct.  lld-link is also the same (which is the same as
ld.lld and the other one), and so is llvm-lib (which is a synonym of
llvm-ar).  All of them work by switching off of the executable name by
looking at argv[0] and then enabling functionality that way.

I don't have a strong opinion on whether it's reasonable to implement
llvm-ml this way.  It seems to make sense on the surface, but I'm not well
versed in this area so someone else may have stronger opinions than I do.

Without question though, having MASM support somewhere in LLVM would be
great, because this (and maybe the MIDL compiler) are the 2 big missing
pieces I'm aware of for having a full cross-compilation toolkit for Windows.

On Wed, Nov 20, 2019 at 1:58 PM Eric Astor <eric.astor at gmail.com> wrote:

> Agreed, I won't plan to change syntax for anything that hasn't opted in.
>
> However... Am I mistaken in thinking clang-cl (for example) is just clang
> with a different name, which triggers some variant behaviors including
> parsing cl.exe-style command lines and taking certain flags as implicit?
>
> I was hoping to build llvm-ml similarly, by building the features into
> llvm-mc behind target selection and/or flags, then providing a different
> driver for implicit ml.exe compatibility.
>
> (Also, are there guidelines for writing an RFC that people will bother
> with, or should I just try not to make it TOO long?)
>
> On Wed, Nov 20, 2019, 12:30 PM Zachary Turner <zturner at roblox.com> wrote:
>
>> I don't think it's a good idea to alter what kind of syntax is accepted
>> or not for files that aren't explicitly opting into MASM behavior.  The
>> usual pattern we have done in the past for MS compatibility tools is to
>> make a separate tool which is named the same as the Microsoft tool, but
>> prefixed with `lld-`, `llvm-` or `clang-`.  E.g. `clang-cl`, `llvm-rc`,
>> `llvm-mt`, `lld-link`.  So in this vein, I think it makes the most sense to
>> have any future LLVM MASM compiler be called `llvm-ml` or `llvm-ml64`.
>>
>> For your second question, I think many people on the list would be
>> willing to & capable of answering questions.  Just post your RFC and
>> someone will look at it (it sometimes takes a few bumps & pings to get
>> people to stop what they're doing though)
>>
>> On Sun, Nov 17, 2019 at 2:08 PM Eric Astor via llvm-dev <
>> llvm-dev at lists.llvm.org> wrote:
>>
>>> Hi all,
>>>
>>> I'm working on a project that uses clang-cl & lld-link to build for
>>> Windows, along with some tools out of the Windows SDK... but we're
>>> currently pre-building some pieces of MASM assembly code using Microsoft's
>>> ml.exe & ml64.exe. Unfortunately, it's not all inline assembly, which clang
>>> can already handle, and Microsoft's file-level directives are a bit unusual.
>>>
>>> I plan to work on getting llvm-mc to compile (relatively simple) MASM
>>> files when targeting a Windows x86-based platform, with goal of matching
>>> the output of ml.exe and ml64.exe. I've already drafted a proof-of-concept
>>> patch that lets llvm-mc handle MASM's variants of conditional assembly
>>> macros (including the idiomatic use of "ifdef rax" to check if a build is
>>> targeting x86-64)... but macro functions & structs are of course looking a
>>> bit harder.
>>>
>>> A few questions:
>>>
>>> 1. Should all of the changes be locked behind an equivalent to clang's
>>> -fms-compatibility flag, or would it be good if some subset of the
>>> functionality were shared? [e.g., should .ifdef rax be a valid way to
>>> check if the rax register exists?]
>>>
>>> 2. Is there anyone around who would be willing to answer questions
>>> regarding the intended architecture of llvm-mc and the AsmParser classes?
>>> I'd like to make sure my proposals fit well into the design... and I'm
>>> starting to have trouble finding where these extensions should go. (Also,
>>> I've had some trouble getting used to the recursive-descent parser
>>> conventions being used. For example, how should one handle "try parsing
>>> this identifier as a register, and if that fails, check if it's defined as
>>> a symbol" while not emitting Errors from the first attempt?)
>>>
>>> Thanks,
>>> - Eric
>>> _______________________________________________
>>> LLVM Developers mailing list
>>> llvm-dev at lists.llvm.org
>>> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20191120/a97c8581/attachment.html>