search for: jevin

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://gith...

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)

...void func(void){} int main(){ func(); return 0; } You could do this: void func(void){} /* You have to initialize this at compile time. */ struct { char* data; int len; void (*ptr)(void) = func; } func_data; int main(){ func_data.ptr(); return 0; } On Jul 18, 2013 12:47 PM, "Jevin Sweval" <jevinsweval at gmail.com> wrote: > 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...

...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 not sure about Python to LLVM. There was Unladen Swallow [3] but that was abandoned a while ago. Cheers, Jevin [0]: https://github.com/nickg/nvc [1]: https://gna.org/projects/ghdl/ [2]: http://dragonegg.llvm.org/ [3]: https://code.google.com/p/unladen-swallow/wiki/ProjectPlan On Mon, Sep 1, 2014 at 8:53 PM, David Blubaugh <davidblubaugh2000 at yahoo.com> wrote: > Has anyone ever did a python to L...

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

...th) | Prefix Data Length (fixed length [32 bits?]) | Function code .... | ^ function symbol points here (function code) I hope the simple ASCII art makes it through my mail client. To access the data, you do prefix_data = function_ptr - sizeof(prefix_length) - prefix_length Cheers, Jevin

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 gmail.com> wrote: On Wed, Jul 10, 2013 at 2:08 PM, Ramkumar Ramachandra <artagnon at gmai...

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

Hi, I would like to propose that we introduce a mechanism in IR to allow arbitrary data to be stashed before a function body. The purpose of this would be to allow additional data about a function to be looked up via a function pointer. Two use cases come to mind: 1) We'd like to be able to use UBSan to check that the type of the function pointer of an indirect function call matches the

On Jul 10, 2013, at 2:30 PM, Eric Christopher <echristo at gmail.com> wrote: > On Wed, Jul 10, 2013 at 2:08 PM, Ramkumar Ramachandra > <artagnon at gmail.com> wrote: >> Jim Grosbach wrote: >>> To say that another way, is the assembler correctly diagnosing a previously >>> unnoticed problem in the project source code, or is the assembler not >>>

Hello all, LLVM's API varies a lot from version to version. Take a example, header llvm/Target/TargetData.h changed to llvm/DataLayout.h from LLVM version 3.1 to version 3.2. This sliced the program just like: #if defined(LLVM_V31) #include llvm/Target/TargetData.h #elif defined(LLVM_V32) #include llvm/DataLayout.h #else #error NEED HEADER The code is in a mess if I want to support

Not subscribed to the list, sorry to mess up the message threading - but to touch on one question that was raised earlier in the day, Bob Wilson wrote: > On Mar 28, 2014, at 4:23 PM, Jevin Sweval <jevinsweval at gmail.com> wrote: > >> Is the LLDB patch missing? I only see libc++, compiler-rt, LLVM, and Clang patches > > We have a patch for LLDB but it is combined with a variety of other changes. Someone will have to go through and sort those out first. I'...

On Wednesday 10 July 2013 22:18:23 Jevin Sweval wrote: > 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? It would help us for sure to build the kernel and others. -- JS

Hi Reid, Thanks for the reply. Comments inline below. Regards, Eric On 9/29/14, 5:51 PM, Reid Kleckner wrote: > I think any port will involve some changes, but it's really hard to > say which porting approach will be the least painless beforehand. > Aside from _MSC_VER incompatibilities messing up portability headers, > I think any changes you make to support clang on Windows