search for: intel_syntax

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 it's a pretty basic t...

...On Feb 15, 2012, at 5:42 PM, Matthew Huck wrote: > Hi, > It doesn't compile with yasm, or nasm Where did you get the idea that "Intel syntax" means NASM? LLVM actually produces assembly files that can be fed to GAS, or to LLVM's MC framework. (In fact, it's missing a .intel_syntax directive so GAS knows it needs to assemble instructions according to Intel syntax.) > (reports invalid combination of opcode and operands), and > > mov _x,EAX > > is meaningless as _x is just a label (an numeric constant that happens to be an address), so it would have to be der...

It looks to me like llvm-mc is doing something strange. Eg: echo "pop ebp" | llvm-mc -assemble -arch=x86 -filetype=obj -o temp.bin Now disassembling temp.bin: $ llvm-objdump -disassemble -x86-asm-syntax=intel -section-headers temp.bin temp.bin: file format COFF-i386 Disassembly of section .text: 0000000000000000 .text: 0: 8f 05 00 00 00 00

Hi, It doesn't compile with yasm, or nasm (reports invalid combination of opcode and operands), and mov _x,EAX is meaningless as _x is just a label (an numeric constant that happens to be an address), so it would have to be dereferenced to get to the memory at that address, otherwise it's like saying mov 0x12341234, EAX Now, my asm skills are not that great, so I'm prepared to be

...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 result as I do for llvm-mc, using the corresponding code: .data foo: .byte 5 .text .intel_syntax mov eax, foo Either way, LLVM emits an object file with disassembly (and relocation) as follows: 0: 8b 04 25 00 00 00 00 mov eax, dword ptr [0] 0000000000000003: IMAGE_REL_AMD64_ADDR32 foo To replicate the results from ml64.exe with LLVM, I instead need...

...1 "crash.c" // Copyright (C) 2020 Stefan Kanthak <stefan.kanthak at nexgo.de> long dummy; __attribute__((naked)) long function(void) { __asm__(".data\n" "dummy:\n" ".quad\t0\n" ".text\n" ".intel_syntax noprefix\n" "\tmov\trax, dummy\n" "\tret\n"); } --- EOF --- --- crash-74a40f.sh --- # Crash reproducer for clang version 10.0.0 # Driver args: "-c" "-m64" "crash.c" # Original command: "C:\\Program Files\\LLVM\\bin\...

...t;> >> long dummy; >> >> __attribute__((naked)) >> long function(void) >> { >> __asm__(".data\n" >> "dummy:\n" >> ".quad\t0\n" >> ".text\n" >> ".intel_syntax noprefix\n" >> "\tmov\trax, dummy\n" >> "\tret\n"); >> } >> --- EOF --- >> >> --- crash-74a40f.sh --- >> # Crash reproducer for clang version 10.0.0 >> # Driver args: "-c" "-m64" &quot...

...will need to be taught the right syntax for operands (i.e. the address of a stack variable is "DWORD PTR [8+ESP]" rather than "8(%esp)"), however. 4. How do we distinguish the assembly dialect at the IR level? One approach would be wrap the asm text passed to the backend with .intel_syntax and .att_syntax. E.g., call void asm sideeffect ".intel_syntax\n\tnop\n\t.att_syntax", "~{dirflag},~{fpsr},~{flags}"() nounwind Besides being rather hackish, this isn't likely going to work. Based on feedback from other internal developers, I would like to propose a sm...

...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 result as I do for llvm-mc, using the corresponding code: .data foo: .byte 5 .text .intel_syntax mov eax, foo Either way, LLVM emits an object file with disassembly (and relocation) as follows: 0: 8b 04 25 00 00 00 00 mov eax, dword ptr [0] 0000000000000003: IMAGE_REL_AMD64_ADDR32 foo To replicate the results from ml64.exe with LLVM, I instead need...

...ked)) >> >> long function(void) >> >> { >> >> __asm__(".data\n" >> >> "dummy:\n" >> >> ".quad\t0\n" >> >> ".text\n" >> >> ".intel_syntax noprefix\n" >> >> "\tmov\trax, dummy\n" >> >> "\tret\n"); >> >> } >> >> --- EOF --- >> >> >> >> --- crash-74a40f.sh --- >> >> # Crash reproducer for clang version 10.0....

...nd last thing , which I don't understand is the weak symbol for __start_xray_instr_map[] __stop_xray_instr_map[] __start_xray_fn_idx[] __stop_xray_fn_idx[] I replace them with __declspec(selectany) , but I'm not sure they have same meanings. some random generated code: .text .intel_syntax noprefix .def call; .scl 2; .type 32; .endef .globl call # -- Begin function call .p2align 4, 0x90 call: # @call .seh_proc call # BB#0: # %entry .p2align 1, 0x90 .Lxra...

I'm learning the xray library and try if it can be built on windows, in xray_fdr_logging_impl.h line 152 , comment written as // Using pthread_once(...) to initialize the thread-local data structures but at line 175, 183, code written as thread_local pthread_key_t key; // Ensure that we only actually ever do the pthread initialization once. thread_local bool UNUSED Unused = [] {

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

...r; >>>>> >>>>> } >>>>> >>>>> } >>>>> } >>>>> >>>>> here .s file: * the code that i want to ask is in red color.* >>>>> >>>>> .text >>>>> .intel_syntax noprefix >>>>> .file "matn_o3.ll" >>>>> .section .rodata,"a", at progbits >>>>> .p2align 6 >>>>> .LCPI0_0: >>>>> .quad 8 # 0x8 >>>>> .quad 9 # 0x...