similar to: [LLVMdev] GSoC Proposal: Table-Driven Decompilation

On 04/04/2012 07:08 AM, Charles Davis wrote: > Hi, > > Here's one of my proposals for GSoC 2012. What do you think? > > Chip > > Project Title: Table-Driven Decompilation > > Abstract: > Over the years, the LLVM family has grown to include nearly every type of build tool in existence. One of the few missing is a decompiler. LLVM's TableGen tool could

On 4/4/2012 12:08 AM, Charles Davis wrote: > Proposal: > Since its humble beginnings in 2001, LLVM has grown from a simple compiler toolkit to an entire family of build tools. Currently, it includes an assembler, a disassembler, a JIT, a C compiler, a debugger, an archiver, various tools for analyzing object files, and even a linker. In fact, just about the only tool missing from this set

Hi - Not sure if anyone else saw this or cares about a decompiler (not personally tested) https://github.com/draperlaboratory/fracture I wonder if they have been in contact with anyone in the community in getting this upstreamed. Does it look interesting to anyone else? (thoughts/random comments/feedback)

On Thu, Apr 3, 2014 at 11:50 AM, Jevin Sweval <jevinsweval at gmail.com> wrote: > On Wed, Apr 2, 2014 at 1:57 AM, "C. Bergström" <cbergstrom at pathscale.com> wrote: >> Hi - >> >> Not sure if anyone else saw this or cares about a decompiler (not personally >> tested) >> https://github.com/draperlaboratory/fracture >> >> I wonder if

> On Mar 5, 2018, at 6:28 PM, Matthias Braun <mbraun at apple.com> wrote: > > > >> On Mar 5, 2018, at 6:14 PM, Andrew Trick via llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: >> >> >> >>> On Mar 5, 2018, at 3:38 PM, Quentin Colombet <qcolombet at apple.com <mailto:qcolombet at

> On Mar 5, 2018, at 6:14 PM, Andrew Trick via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > > >> On Mar 5, 2018, at 3:38 PM, Quentin Colombet <qcolombet at apple.com <mailto:qcolombet at apple.com>> wrote: >> >> When Ahmed and I worked on the decompiler, we first targeted MC. Going to MI was more difficult and really wouldn’t have gotten us a

Hi, I know most compilers go from AST to CFG. I am writing a decompiler, so I was wondering if anyone knew of any documents describing how best to get from CFG to AST. The decompiler project is open source. https://github.com/jcdutton/libbeauty The decompiler already contains a disassembler and a virtual machine resulting in an annotated CFG. It uses information gained from using a virtual

Hi, What does llvm use for testing. The area of testing I am interested in are how to test the accuracy of the assembler/disassembler. So, if you take an IR level instruction. How do you verify that the generated CPU specific instruction is correct? Is there an automated method for this? I wish to implement automated testing on a decompiler I am writing, and thought that the test methods used in

On Tue, Mar 6, 2018 at 5:55 AM, Andrew Trick via llvm-dev < llvm-dev at lists.llvm.org> wrote: > > > On Mar 5, 2018, at 6:28 PM, Matthias Braun <mbraun at apple.com> wrote: > > > > On Mar 5, 2018, at 6:14 PM, Andrew Trick via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > > > > On Mar 5, 2018, at 3:38 PM, Quentin Colombet <qcolombet at

Hi, I am writing a decompiler. I was wondering if some of LLVM could be used for a decompiler. There are several stages in the decompiler process. 1) Take binary and create a higher level representation of it. Like RTL. 2) The output is then broken into blocks or nodes, each block ends in a CALL, JMP, RET, or 2-way or multiway conditional JMP. 3) The blocks or nodes are then analyzed for

Hi, Simon Moll (in CC) has written a decompiler for LLVM in his Bachelor's Thesis here at Saarland University. The thesis is titled "Decompilation of LLVM IR" and can be found here: http://www.cdl.uni-saarland.de/publications/ The library he implemented is called "Axtor" (for "AST Extractor") and has been used primarily to generate OpenCL code from LLVM. In

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

Hi, Is decompilation possible in general to the SSA form for binaries? I assume one has to make certain assumptions about code in general to get tools like these to work. For example if code like with dlsym or jit heap allocated functions can be incorporated at runtime it would seem that in general it is quite difficult to ascertain the boundaries of a basic block and insert the correct phi

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"

> -----Original Message----- > On Behalf Of James Courtier-Dutton > To: John Criswell > > On 7 May 2012 16:31, John Criswell <criswell at illinois.edu> wrote: > > On 5/7/12 5:47 AM, James Courtier-Dutton wrote: > >> > >> Hi, > >> > >> I am writing a decompiler. I was wondering if some of LLVM could be > >> used for a

On 5/7/12 5:47 AM, James Courtier-Dutton wrote: > Hi, > > I am writing a decompiler. I was wondering if some of LLVM could be > used for a decompiler. > There are several stages in the decompiler process. > 1) Take binary and create a higher level representation of it. Like RTL. > 2) The output is then broken into blocks or nodes, each block ends in > a CALL, JMP, RET, or

Could you please expand a bit? Why are not the MCInstr and MachineInstr classes compatible? Is this not a long term goal, even? Could I make optimization passes in the MC layer with a disassembler as in a MachineFunction? Thanks, Jonas -----Original Message----- From: Eric Christopher [mailto:echristo at apple.com] Sent: Friday, February 17, 2012 8:20 PM To: Jonas Paulsson Cc: LLVMDEV

On Friday 10 July 2009 00:19, Chris Lattner wrote: > asmprinter::printInstruction will lower a MachineInstr to an MCInst, > then call the MCInst asmprinter to do the hard formatting work. You > can see a horrible simple skeleton of this idea in > X86ATTAsmPrinter::printMachineInstruction. Yep, that's where I hit the problem. I'm patching the sources for the comment emitter

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

On 21 September 2012 09:51, Ralf Karrenberg <Chareos at gmx.de> wrote: > Hi, > > Simon Moll (in CC) has written a decompiler for LLVM in his Bachelor's > Thesis here at Saarland University. The thesis is titled "Decompilation of > LLVM IR" and can be found here: > http://www.cdl.uni-saarland.de/publications/ > > The library he implemented is called