similar to: [LLVMdev] decompiler

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 Thu, Mar 12, 2015 at 05:44:02PM -0700, Daniel Dilts wrote: >> Does there exist a tool that could lift a binary (assembly for some >> supported target) to LLVM IR? If there isn't, does this seem like >> something that would be feasible? There's plenty of variations on the idea: Revgen/S2E, Fracture, Dagger (my own), libcpu, several closed-source ones used by

Hi All, 2 of my summer interns (Aimee Dipietro and Greg Simpson) used their time over the summer to resurrect the LLVM C Backend: https://github.com/draperlaboratory/llvm-cbe Improvements include recovery of simple for/while loops (instead of goto), better variable naming, inline asm support, and making it work on a more recent version of llvm. I believe they used the repository here as a

On 3/12/15 8:14 PM, Daniel Dilts wrote: > On Thu, Mar 12, 2015 at 6:33 PM, Ahmed Bougacha > <ahmed.bougacha at gmail.com <mailto:ahmed.bougacha at gmail.com>> wrote: > > > On Thu, Mar 12, 2015 at 05:44:02PM -0700, Daniel Dilts wrote: > >> Does there exist a tool that could lift a binary (assembly for some > >> supported target) to LLVM IR?

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

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 potentially accelerate development of such a tool; most backends already have the information needed

Does there exist a tool that could lift a binary (assembly for some supported target) to LLVM IR? If there isn't, does this seem like something that would be feasible? -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150312/36eae2e4/attachment.html>

Hi all! There is doc about tglben backends: http://llvm.org/docs/TableGen/BackEnds.html May be should to add link at https://github.com/draperlaboratory/fracture/wiki/How-TableGen%27s-DAGISel-Backend-Works I remember when I first met the LLVM it would be very useful. -------------- next part -------------- An HTML attachment was scrubbed... URL:

I agree, but I have no experience with LLVM doc. The job is very simple: add link at page https://github.com/draperlaboratory/fracture/wiki/How-TableGen%27s-DAGISel-Backend-Works into doc page http://llvm.org/docs/TableGen/BackEnds.html But how I can do it? On Tue, Jun 3, 2014 at 4:41 PM, Renato Golin <renato.golin at linaro.org> wrote: > Hi Daniil, > > Those look great! I think

The only VHDL to LLVM project that I know of is nvc. [0] I haven't tried it personally and from a cursory look through the source it seems like there is a LLVM backend and a "native" backend (not sure what that means). If you're really crazy you might want to see if you could massage GHDL [1] (VHDL GCC frontend) + DragonEgg [2] (LLVM backend for GCC) to get you LLVM IR. I'm

On Wed, Jul 17, 2013 at 9:06 PM, Peter Collingbourne <peter at pcc.me.uk> wrote: > > To maintain the semantics of ordinary function calls, the prefix data > must have a particular format. Specifically, it must begin with a > sequence of bytes which decode to a sequence of machine instructions, > valid for the module's target, which transfer control to the point >

Thanks Andrea for working on this! I’ve been willing to do this for quite some time now. Looks like procrastination was the right approach here ;). > On Mar 2, 2018, at 9:33 AM, Andrew Trick via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > +Ahmed > >> On Mar 2, 2018, at 6:42 AM, Andrea Di Biagio <andrea.dibiagio at gmail.com <mailto:andrea.dibiagio 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

As much as I like this idea for it's use in languages with type systems like Haskell and Scheme, this proposal would limit LLVM to non-Harvard architectures. That's generally a really small minority of all processors, but it would mean there could never be a clang-avr. An alternative you could use is, instead of using the function pointer as the variable where you are referring to a

Dear all, I use the clang frontend to produce the control flow graph of a C program through this command: clang -Xclang -analyze -Xclang -analyzer-checker=debug.DumpCFG test.c The produced information contains all the basic blocks identified by labels, e.g. B1, B2, etc. along with their predecessors and successors. Is there a way to get the starting address of each of these basic block? I would

> On Mar 5, 2018, at 3:38 PM, Quentin Colombet <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 lot of benefits. Instead, Ahmed pushed for directly decompiling to IR (look for dagger). Thanks for the pointer Quentin. > I would actually be in favor for more

Dear All I have disassembled the object file on my CentOS server , by the following : #objdump wmain In the output , I have recognized the intended subroutine that I need to find the exact command syntax that it sends out . To this end , I tried to capture it through 'tcpdump' but didn't success . I read this segment assembly language code but it is somewhat difficult to decode . Can

http://www.cs.fsu.edu/~baker/devices/lxr/http/source/linux/arch/x86/include/asm/bitops.h#L68 Here is one example that I found. Are the inline assembly arguments ambiguous in size? -Jevin Sent from my mobile device. Typos are par for the course. On Jul 10, 2013, at 5:47 PM, Jim Grosbach <grosbach at apple.com> wrote: On Jul 10, 2013, at 2:30 PM, Eric Christopher <echristo at

On Fri, Jun 3, 2016 at 11:53 AM, Ahmed Bougacha <ahmed.bougacha at gmail.com> wrote: > -llvmdev at cs.uiuc.edu, that list isn't in use anymore. > > On Wed, Jun 1, 2016 at 4:48 PM, Kenneth Adam Miller via llvm-dev > <llvm-dev at lists.llvm.org> wrote: > > Hello all, > > > > I would like to restrain the compiler that I build on my local box from >

On Mar 28, 2014, at 3:32 PM, Bob Wilson <bob.wilson at apple.com> wrote: > There are new conflicts several times a day, on average. I rebased them on Wednesday on top of svn 204791. If you want to try them out, it would be best to roll back to that revision. > > I’ll rebase them one more time when we commit them, but it’s such a moving target (and takes a fair bit of work), that