similar to: [LLVMdev] LLVM binaries for Windows and more

> -----Ursprüngliche Nachricht----- > Von: asl at math.spbu.ru, LLVM Developers Mailing List <llvmdev at cs.uiuc.edu> > Gesendet: 13.06.07 23:13:08 > An: LLVM Developers Mailing List <llvmdev at cs.uiuc.edu> > Betreff: Re: [LLVMdev] LLVM binaries for Windows and more > > Hello, Andreas. > > > It seems that the generated ASM code cannot be assembled

Hello, Benedict >As far as I can tell it seems that the LLVM x86 backend targets GNU >assembler with DWARF for debug and there is not a way, currently, to >output for MS assembler with COFF debug info. Is this correct or am I >just looking at the wrong part? Multiple issues here, actually. First of all, there is "X86IntelAsmPrinter", which outputs MASM-compatible assembler.

Hi Anton, Ok maybe I should have stated what it was that I wanted to do. In this context I would like to compile C code, with LLVM, to MS proprietary CV format that can be linked and debugged with Visual Studio, but from what you are saying this is not currently possible. Thanks, Ben -----Original Message----- From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On

On Sun, 30 Apr 2006, Jeff Cohen wrote: Jeff, many appologies. I slightly misread what you wrote, and came across more strongly that was appropriate: I'm sorry! :( :( > Let's see. Ralph correctly points out that LLVM isn't producing anything > like Intel syntax. ... This is not true. LLVM produces something very close to what GAS accepts in intel mode: that is, we

Hi, We have a significant regression since llvm 5.0.0 in the x86 assembler. The following snippets fail: 1) .intel_syntax 0: jmp 0b 2) .intel_syntax and edi, 0b010101 when running through `llvm-mc -arch x86-64`. This regression was introduced in r301390, which was driven by PR27884. I think https://llvm.org/PR36144 describes this very well, and I think we should get this fixed, since

Interesting - the patch doesn't address this yet. It looks like we have a difference (maybe bug?) in how we handle Intel vs. AT&T inline assembly: https://godbolt.org/z/GQw9ED Suppose we're expanding an operand with an 'i' constraint, where the operand is given as, e.g. (i32* @Bar). If the inline assembly is in Intel dialect, this expands as "Bar" in AT&T syntax

Hello, Henrik. You wrote Tuesday, July 12, 2005, 3:49:07 PM: B> Are the MASM backend compatible with the MS version of MASM or other not so HB> license restrictive versions of or similar to MS MASM? Btw, maybe, it will be fine, if this backend will be tested for work with YASM? (http://www.tortall.net/projects/yasm/). It seems, that YASM grows fast during last months. It also supports

Yes, you are right. During my testings, I tried the llvm produced .S files with the gcc frontend and it compiled and linked them to the final executable. The problem is with the gcc and binutils licence. This is GPL and while this is ok for open source or for academic purposes, it can't be used on commercial projects. In fact one of the strong points of llvm (and clang) is its BSD like

> > I volunteer. As soon as I get everything to work. > > > > Next problem: I now have the hello.bc file compiled. But how do I get an executable from this? I tried: > > > > C:\Eigenes\compiler\llvm-2.0\win32\release>llvm-ld -o=hellow.exe hellow.bc > > llvm-ld: Could not find llvm-stub.exe executable! > > > > So, I don't have

On Jan 21, 2010, at 2:01 PM, Jim Crafton wrote: >> Nope, llvm's .s output is only compatible with GAS and other at&t >> syntax >> assemblers. It turns out that MASM syntax is highly ambiguous and >> MASM is >> not production quality for use by a compiler. This is why visual >> studio >> doesn't go through it. Long term, we'd like

On Jan 28, 2010, at 11:51 AM, Dustin Laurence wrote: > On 01/28/2010 11:41 AM, Anton Korobeynikov wrote: >> >> The required efforts equal to ones required to write new assembler. >> "Too weak to be usable" means "it's not possible to represent many >> important constructs with masm/nasm/fasm". > > Wow. It's perhaps too much of a

I have one thing not clear to me. If the llvm diect generate object code. Then how about the llvm assembler processing llvm code with inline assembly? Indeed, it's seems now llvm is direct using gas syntax in the assembly code. And because it's generate .S files, so it can be manipulated by binutils. But there is one day, no binutils any further, how to deal with these inline assembly.

On Wed, Oct 3, 2012 at 1:19 AM, Jim Grosbach <grosbach at apple.com> wrote: > What's the use case? the use case is that we can print out the assembly using alternative dialect. currently, on Intel machine, the default dialect is AT&T, and we cannot change that to Intel syntax without using cl:opt. the new public method lets us change the dialect without having cl:opt involved.

Hi Chris, > The LLVM X86 backend started out emitting intel mode for use with GAS > and it's "intel syntax mode" (which does use registers with %'s). > Unfortunately GAS has (or commonly available versions have) a number > of bugs in intel syntax mode (e.g. you can't define a function named > 'dword'), so we switched to using AT&T syntax. Ah, OK.

Ok, less talk and more action. I just implemented proper Microsoft ML/MASM support. It probably has a few rough edges, so if anyone wants to try it out please do and let me know if you encounter any problems. Note that you cannot take a bytecode file created by llvm-gcc on Unix, move it to Windows, translate it to Intel syntax assembler, assemble it with ML and expect it to work.

It would be nice to be able to use clang/llvm without GNU toolchain dependencies. Just out of curioisty what does the --x86-asm-syntax=intel actually mean then? Does this not get used? Is this a different syntax than the AT&T variety (forgive me if this is an obvious question)? I tried downloading FASM last night and it seemed handle some of the output, the one thing it didn't like was

Razvan, You're somewhat misinterpreting the GPL license. Using binutils as a dependency of LLVM does not require that they be linked into any distributable that might contain proprietary code. They can be shipped as separate, purely-GPL'd executables that are called via the command line, thereby avoiding the whole "infection" problem. This is, for instance, how

On Sat, 29 Apr 2006, Jeff Cohen wrote: > We know. Someone offered to do the Intel version, but did little more than a > huge cut and paste of the AT&T version and then lost interest. No one else > has had the time or inclination to finish the (barely begun) job. Patches > accepted :) Actually, that's not true. The LLVM X86 backend started out emitting intel mode for

On Jan 21, 2010, at 12:54 PM, Jim Crafton wrote: >> By default, the cmake build generates Visual Studio project files for >> the X86 target only. Take a look at >> >> http://www.llvm.org/docs/CMake.html#llvmvars >> >> for learning how to build other targets. > > OK thanks, I'll look at that. > > In the meantime, is it possible to get the

I made some researches how llvm, possibly with other tools, can be a full backend for compiler writers (with the final result being an executable file or dynamic linked library). Here are the results: A. Assemblers When I saw that the I86 target for llvm with the Intel syntax targets MASM (I tested with the MASM version from http://www.masm32.com/ ), it was a bad surprise for me. This is