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

Eric Astor via llvm-dev llvm-dev at lists.llvm.org
Sun Nov 17 14:07:47 PST 2019

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?)

- Eric
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20191117/cdb7588d/attachment.html>

More information about the llvm-dev mailing list