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 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20191117/cdb7588d/attachment.html>
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/d62648b4/attachment-0001.html>
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/d7d703d3/attachment.html>