similar to: MASM & RIP-relative addressing

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]

Are you asking what the parsing rules are, or how you should modify the LLVM code to achieve that result? If the latter, you haven’t really given enough detail here. What code, exactly, have you tried modifying? Do you have any ideas for how it could work? -Eli From: Eric Astor <epastor at google.com> Sent: Tuesday, January 21, 2020 2:44 PM To: Eli Friedman <efriedma at

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.

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

Hello, I'm working on an LLVM backend for an experimental microprocessor. Work is going on nicely, and I've until now found the answer to all my questions directly in the LLVM source code, or in the documentation. However, I'm having problems with the AsmBackend class and the handling of fixups. The processor I'm working with has a single conditional branch instruction, JCC,

I met with the Propeller team today (we work for the same company but it was my first time meeting two members on the team:) ). One thing I have been reassured: * There is no general disassembly work. General disassembly work would assuredly frighten off developers. (Inherently unreliable, memory usage heavy and difficult to deal with CFI, debug information, etc) Minimal amount of plumbing work

On Tuesday 16 June 2009 09:48, Aaron Gray wrote: > Appently the GAS Intel backend has flaws and does not work correctly anyway > so the X86IntelAsm backend is designed only to target MASM anyway. gas Intel syntax is indeed broken in LLVM. I'd love to make it work but my work has not (yet) allocated time for that. Maybe I can hack LLVM on the weekends. :) The above discussion leads

>On Mon, Jun 15, 2009 at 5:49 PM, Gaster, >Benedict<Benedict.Gaster at amd.com> wrote: >> I would like to use the LLVM x86 code generator to emit Intel syntax that >> is >> compatible with Microsoft’s MASM 9.x. Taking the TOT LLVM, from last >> week, I >> have found a number of changes that are required to make this work, most >> of >> which

>> I am not really sure whether to do a X86NASMPrinter or whether to bypass >> that for now and work on an X86COFFWriter which would be more useful to >> me ? > > I wouldn't suggest writing an X86NASMPrinter: just change the current > Intel printer to do what you want. Noone is currently using the intel > printer, so you can do what you wish to it. Once I

> On Mon, 2005-07-11 at 19:24 +0100, Aaron Gray wrote: >> The NASM like the MASM does not have % symbols on the register names so >> will >> either inherit from the MASM printer or have its own TableGen class. > > Couldn't one conditionally output some macros for the assembler to > translate the reg names rather than having another .td file? or is '%'

On Jun 16, 2009, at 3:12 PM, David Greene wrote: > On Tuesday 16 June 2009 09:48, Aaron Gray wrote: > >> Appently the GAS Intel backend has flaws and does not work >> correctly anyway >> so the X86IntelAsm backend is designed only to target MASM anyway. > > gas Intel syntax is indeed broken in LLVM. I'd love to make it work > but > my work has not

Here's the new MASM backend. It has the following files :- lib/Target/X86/X86AsmPrinter.h lib/Target/X86/X86AsmPrinter.cpp lib/Target/X86/X86MASMPrinter.h lib/Target/X86/X86MASMPrinter.cpp lib/Target/X86/X86.td lib/Target/X86/X86InstrInfo.td lib/Target/X86/makefile Makefile.rules win32/x86/x86.vcproj

On Mon, Jun 15, 2009 at 11:21 PM, Gaster, Benedict<Benedict.Gaster at amd.com> wrote: > I can get this two work with additional changes to X86InstrInfocpp but > the problem I have with this approach is that it introduces a lot of > duplication, when all I really want to do is parameterize the final > field in the string "shl{b}\t{%cl, $dst|$dst, %CL}". I was wondering

On Mon, 2005-07-11 at 19:24 +0100, Aaron Gray wrote: > The NASM like the MASM does not have % symbols on the register names so will > either inherit from the MASM printer or have its own TableGen class. Couldn't one conditionally output some macros for the assembler to translate the reg names rather than having another .td file? or is '%' not a valid part of a macro on NASM?

Even the latest version of MASM does not support the CMOVcc instructions (unless they are named something different my Microsoft ?). Using the CMOVcc instruction rules the X86 out for compilation to pre Pentium Pro CPU's. Aaron -------------- next part -------------- An HTML attachment was scrubbed... URL:

On Tue, Jun 16, 2009 at 9:39 AM, Gaster, Benedict<Benedict.Gaster at amd.com> wrote: > Hi Eli, > > Yep I was being stupid. > > Please find attached a patch for initial changes to get MASM working. Patch looks fine except that it has tabs (LLVM uses only spaces for indentation). Also, can you generate the patch using "svn diff"? It's currently in some unusual

> On Tuesday 16 June 2009 09:48, Aaron Gray wrote: > >> Appently the GAS Intel backend has flaws and does not work correctly >> anyway >> so the X86IntelAsm backend is designed only to target MASM anyway. > > gas Intel syntax is indeed broken in LLVM. I'd love to make it work but > my work has not (yet) allocated time for that. Maybe I can hack LLVM on >

2009/8/3 Anton Korobeynikov <anton at korobeynikov.info> > >> Anyway I wll report back when I have a proper overview of the area, > >> it would be good if you could also look into the problem so contact > >> me back if you are, also it maybe a good idea to share this with > >> Anton and Evan. > > > > I already spoke to anton. The MASM

Hi Eli, Yep I was being stupid. Please find attached a patch for initial changes to get MASM working. There is still one problem that I am looking into around changing alignments within SEGMENTS. The problem is that MASM allows 2,4,16,256 alignments, default being 16, but LLVM is sometimes generating 32 alignment, for example, consider the following code: float bar(float fy, float fx) {

On Aug 3, 2009, at 11:23 AM, Aaron Gray wrote: > Hi Chris, > > It would be good to get to try to get it as functional as possible > at some point, before abandoning it..maye once I have one the COFF > backend. I'm not proposing to remove COFF support from the asmprinter, just masm support. Using gas will continue to work fine. > Anyway I wll report back when I have