similar to: [LLVMdev] Query about ARM support in LLVM MC Project

That depends on how you define "one ARM instruction." It's not a clear cut thing. For example, is "add r1, r2, r3" the same ARM instruction as "add r1, r2, #4"? What is a distinct instruction and what's a variant encoding of the same instruction is often entirely a matter of convenience. -Jim On Jun 8, 2012, at 6:40 AM, Fan Dawei <fandawei.s at

Hi Jim, Thanks for reply. I'm sorry I didn't make myself clear enough. The MCInst created by MCDisassembler depends on the instructions defined in td files. These instructions do not have a one to one mapping to ARM instructions. There are usually one or more instructions defined in the td file correspond to one actual ARM instruction. Thanks, David On Thu, Jun 7, 2012 at 1:27 PM, Jim

On Jun 7, 2012, at 7:53 AM, Fan Dawei <fandawei.s at gmail.com> wrote: > Hi Tim, > > Thanks a lot for your help! I'm very grateful. > > libc.so is a prelinked library, I'll build a non-prelinked one and have another try. > > I'm now at the start of a binary translation project. I want to convert ARM binary code [*] to llvm ir, which is then translated to

In r198030 the last in tree backend was converted to use MCInst for printing assembly. I removed support for the old printer in r198959. Out of tree targets have to lower MachineInstr to MCInst to use the new printer. Cheers, Rafael

Hi, Imagine that your backend has valid asm instruction written like this: "%x mnem %y, %z" And user puts it as inline assembler: __asm__ ("%x mnem %y, %z"); It can not be parsed with current llvm asm parser, because it starts with % (moreover it has mnemonic in second place) Say you written pass, that makes it "mnem %x, %y, %z". Now this guy can be parsed, but

Hi Tim, Thanks a lot for your help! I'm very grateful. libc.so is a prelinked library, I'll build a non-prelinked one and have another try. I'm now at the start of a binary translation project. I want to convert ARM binary code [*] to llvm ir, which is then translated to binary for our mips like architecture. That's why I'm looking for a decoder for ARM binary. The

Hi all, In RISC-V ISA, the range of conditional branches is within 4KiB. In current implementation, if the branch target is out of range, LLVM MC will issue an error message to tell users it could not resolve the fixup record. I have compared the result with the GNU assembler. GNU assembler will convert the branch to inverted one plus jump to make the branch possible. The range of unconditional

On Mar 5, 2010, at 3:20 PM, Wayne Anderson wrote: > Hello, > > I'm interested in the status of LLVM-MC. My particular interest is in > generating executables for ARM embedded applications. I assume this > application is not terribly high on the priority list, so I would like > to know how I can contribute. Can someone point me to some > information and/or

On Jul 9, 2009, at 5:34 PM, David Greene wrote: > Can someone explain what MCInst is vs. MachineIntr? Sure. MCInst is designed to be part of the "MC" set of libraries, which is stuff dealing with machine code. We're building a suite of assemblers and disassemblers out of this. MCInst is integral to this plan. For an assembler you have two pieces: 1. "Recognize"

Hi, By way of example, I have the following instruction: 44 8b 80 c8 03 00 00 movl 968(%rax), %r8d 1) How is this represented in MCInst? 2) Is there information in MCInst that would tell me which bytes of the instruction are responsible for the 968? The reason I am asking is that I want to work with the bytes disassembled/decoded to an instruction at MCInst level.

Hi everyone, Rafael has graciously given me some pointers for helping out on the ARM/MC .s emission infrastructure, and I am volunteering to do so. It looks like as of yesterday, the MC obj emitter for ARM is also incomplete (there does not seem to be a ARMMCCodeEmitter.cpp, for example) So if anyone already has started looking into this, I'd like to pool info so as to not step on toes. Any

Hi All, A self-follow up and rephrase of my previous question with updated subject: What I want to do is to analyze hand-written assembly code with 'full details' where semantics of each instruction can be known in LLVM passes. Many of such instructions have no corresponding counterparts in IR/MIR forms, such as 'syscall' 'iret', etc. At MC level, such assembly code can

Hello, I have some questions regarding folding operations with symbols during the instruction print stage with MC. At the moment I'm working with global symbols but i guess that other symbol types should be equivalent. My first question is how can i negate the address of a symbol? Consider this piece of code: char g_var[80]; char foo(int a) { return g_var[a]; } this gets compiles into

On 3/17/15 3:19 PM, Steve King wrote: > Doesn't count for much, but I'm sympathetic to Dario's concern with > cl::opt and clang defaults. In one large out-of-tree project, > colleagues decided to create their own driver to handle the required > customization of the build process and options. > > If clang is the user's one stop shop, here's one such cross

This sounds very similar to what PowerPC does, see: https://github.com/llvm/llvm-project/blob/master/llvm/lib/Target/PowerPC/PPCBranchSelector.cpp However, PowerPC is doing this in the compiler backend, not in the assembler. One issue is that the process must be iterative, because branches can go both forward and backward, and replacing some branch instructions with the branch pairs can then

Can someone explain what MCInst is vs. MachineIntr? I'm porting some patches we have here that affect MachineInstrs and am wondering whether I need to make similar changes in MCInst. Why do we have two machine instruction representations? -Dave

+llvmdev -llvmcommits On Fri, Nov 12, 2010 at 8:03 AM, Jim Grosbach <grosbach at apple.com> wrote: > Sorta. getBinaryCodeForInst() is auto-generated by tablegen, so shouldn't be modified directly. The target can register hooks for instruction operands for any special encoding needs, including registering fixups, using the EncoderMethod string. For an example, have a look at the

Thanks Andrew and Renato, One think I didn't mention, and I should probably made it more explicit in my RFC is that: "the new predicate framework is extensible". That means, developers can extend it by adding new Check predicates. As long as they also teach the PredicateExpander how to do the lowering for those new predicates, then everything should be fine. -- In the RFC I

Hello, There is an issue in the latest Sparc code: while we can encode POPC, decode results in crash in llvm-mc $ echo "popc %g1, %g2" | ./Release+Asserts/bin/llvm-mc -assemble -triple=sparcv9 -show-encoding .text popc %g1, %g2 ! encoding: [0x85,0x70,0x00,0x01] $ echo "0x85,0x70,0x00,0x01"|./Release+Asserts/bin/llvm-mc -disassemble -triple=sparcv9

Hi, Dear LLVM Dev Group, I am doing an LLVM project aimed to disassemble an ARM ELF binary executable to the MCInst format, inserting some instructions or doing some modification, and re-assemble the MCInst to an ELF binary. As I used the llvm-mc, it seems to only have the option "llvm-mc -disassemble", which reads strings and output strings. Is there any command or function that can