search for: ml64

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 outp...

...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) > > O...

Apologies - I apparently remembered part of the issue incorrectly, so this ended up quite confusing. The problem comes when referencing labels in a different section of the binary. To clarify, if I assemble the code: .data foo BYTE 5 .code mov eax, foo with Microsoft's ml64.exe, it emits an object file disassembling to: 0: 8b 05 00 00 00 00 mov eax, dword ptr [rip] 000000000000000b: IMAGE_REL_AMD64_REL32 foo On the other hand, if I use my current local draft of llvm-ml, I get a different result. I actually get the same...

...work? -Eli From: Eric Astor <epastor at google.com> Sent: Tuesday, January 21, 2020 2:44 PM To: Eli Friedman <efriedma at quicinc.com> Cc: llvm-dev <llvm-dev at lists.llvm.org> Subject: [EXT] Re: [llvm-dev] MASM & RIP-relative addressing Clarifying a minor copy/paste error, ml64.exe actually outputs: 0: 8b 05 00 00 00 00 mov eax, dword ptr [rip] 0000000000000002: IMAGE_REL_AMD64_REL32 foo In other words, the relocation info is the same... but the instruction uses RIP-relative addressing, not absolute. On Tue, Jan 21, 2020 a...

Hi all, Continuing work on llvm-ml (a MASM assembler)... and my latest obstacle is in enabling MASM's convention that (unless specified) all memory location references should be RIP-relative. Without it, we emit the wrong instructions for "call", "jmp", etc., and anything we build fails at the linking stage. My best attempt at this so far is a small patch to

Hi there LLVM is a great idea, congratulations. Do you mind if I give you a little bit of constructive criticism from the point of view of a developer who would like to use LLVM as a back-end? I will write this email from the point of view of MS Windows, but the same applies to MacOS and Linux. LLVM is difficult/awkward to use in a real-world environment/situation. To solve this problem,

Hi all, While working on alias support for the LLVM-ML project, I ran into a feature implemented back in 2010: default-null weak externals in COFF, a GNU extension. https://reviews.llvm.org/rG17990d56907b I'd like to disable this feature when targeting MSVC compatibility. Does anyone have more context on this, and why it'd be a terrible idea? For context: This seems to be designed to let