similar to: [LLVMdev] LLVM C binding for assembly output

There was some talk on IRC last week about desire for Python bindings to LLVM's Object.h C interface. So, I coded up some and you can now find some Python bindings in trunk at bindings/python. Currently, the interfaces for Object.h and Disassembler.h are implemented. I'd like to stress that things are still rough around the edges, so use at your own risk. I intend to smooth things over in

Hello, Am Donnerstag, 15. März 2012, 21:15:02 schrieb Gregory Szorc: > There was some talk on IRC last week about desire for Python bindings to > LLVM's Object.h C interface. So, I coded up some and you can now find > some Python bindings in trunk at bindings/python. Currently, the > interfaces for Object.h and Disassembler.h are implemented. FYI: I recently startet working on

The following is a brief proposal for annotated assembly (and disassembly) output. Kevin Enderby and I have been discussing this a bit and are interested in getting broader feedback from interested folks. LLVM Rich Assembly Output LLVM's (dis)assembly output is currently very raw. Consumers have limited ability to introspect the instructions' textual representation or to reformat for

How is the client supposed to make use of this markup information? At first glance it seems like client code will just devolve into a pile of regex insanity. Why not use an existing standardized markup, like XML (not that I'm that fond of XML)? At a higher level, why not expose an API for iterating over (potentially annotated) tokens which can be programmatically inspected. So what you expose

1) The definition of FLAC__BitWriter was updated with the current text from /libFLAC/bitwriter.c (the text in comments was changed). And the definition of TOTAL_BITS was made closer to the code from /libFLAC/bitwriter.c. 2) The values for 'words' and 'bits' values now calculated, not just some magic constants. 3) Added FLAC__U64L() for 64-bit constants. It seems that it

Hi Jim, thanks for the response. That pretty much clears up my primary concern. +1 for keeping the C API small/stable/robust :) Having multiple hand-implemented parsers accepting the output, I think it would be wise to have an official "conformance suite" for the syntax so that external implementors can sleep more soundly with their implementation; if I were implementing a parser for

Yeah, that's probably how I'd do it. Might be useful if you guys want to contribute that as a command line option Kevin. -eric On Tue, Jun 24, 2014 at 3:03 PM, Kevin Modzelewski <kmod at dropbox.com> wrote: > We do this in Pyston using a JITEventListener that just disassembles the > output; it's "it works let's move on"-quality: >

Hi Sean, Thanks for the feedback! Exactly the sort of discussion I was hoping to get started. On Oct 12, 2012, at 10:12 AM, Sean Silva <silvas at purdue.edu> wrote: > How is the client supposed to make use of this markup information? Target-independent introspection of the assembly. A simple example is color-coded output in a GUI disassembly display. All registers show up one color,

Eli Gottlieb <eligottlieb at gmail.com> writes: > I compiled and installed it to the prefix /usr, but that's not the > issue. Once I actually compile and install LLVM with CMake by hand, I > get the share/llvm/cmake stuff installed correctly (can those files be > included in "normal" builds, or will LLVM switch to CMake as its > primary build system?). Now

Here is the patch that allows to set FLAC__BYTES_PER_WORD to 8. This is disabled by default though. To test FLAC__BYTES_PER_WORD==8: open src/libFLAC/bitreader.c, src/libFLAC/bitwriter.c, src/test_libFLAC/bitwriter.c and change '#if 1' to '#if 0'. The value of FLAC__BYTES_PER_WORD must be the same in src/libFLAC/bitwriter.c and src/test_libFLAC/bitwriter.c. OTOH, their value in

Dagobert Michelsen wrote: > There compilation on Solaris 10 Sparc with Sun Studio 12 gives the following compile errors: > > > CC bitreader.lo > > "bitreader.c", line 494: warning: implicit function declaration: MIN > > CC bitwriter.lo > > "bitwriter.c", line 273: reference to static identifier "bitwriter_grow_" in extern

Another question: What kind of documentation you are planning to produce for this feature? -- Sean Silva On Fri, Oct 12, 2012 at 4:36 PM, Jim Grosbach <grosbach at apple.com> wrote: > > On Oct 12, 2012, at 1:07 PM, Sean Silva <silvas at purdue.edu> wrote: > >> Hi Jim, thanks for the response. That pretty much clears up my primary >> concern. +1 for keeping the C

there is an if-else code in X86DisassemblerDecoder.c that does exactly the same thing on both paths. so this patch removes the redundant path. thanks, Jun diff --git a/lib/Target/X86/Disassembler/X86DisassemblerDecoder.c b/lib/Target/X86/Disassembler/X86DisassemblerDecoder.c index 20e61da..3932ea1 100644 --- a/lib/Target/X86/Disassembler/X86DisassemblerDecoder.c +++

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

Hi, I'm trying to annotate the final assembly output of my llvm codegen with the corresponding input C statements. It would've been super easy if the source information were included in the IR debug info. But obviously they are not, and there are good reasons why not ! So I'm bound to collecting all my information in the back-end from the existing debug pseudo instructions. As you

On Mon, Apr 15, 2013 at 3:17 PM, Alireza Moshtaghi < Alireza.Moshtaghi at synopsys.com> wrote: > Hi, > I'm trying to annotate the final assembly output of my llvm codegen with > the corresponding input C statements. > It would've been super easy if the source information were included in the > IR debug info. But obviously they are not, and there are good reasons why

Hello All, I'm building an F# binding for LLVM and it seems to be working for the parts of Core and BitWriter that I've tested but I've hit problems with Target/ExecutionEngine. The following test code works with the initializeNativeTarget line commented out like so: <https://github.com/keithshep/llvm-fs/blob/b7050b841108dc703e58563a4cff8845603c950d/test/simpletest2.fs> ...

On Oct 12, 2012, at 1:07 PM, Sean Silva <silvas at purdue.edu> wrote: > Hi Jim, thanks for the response. That pretty much clears up my primary > concern. +1 for keeping the C API small/stable/robust :) > > Having multiple hand-implemented parsers accepting the output, I think > it would be wise to have an official "conformance suite" for the > syntax so that

After I actually get everything compiling, install the library, and load it from my Java program, I get the following: > Exception in thread "main" java.lang.UnsatisfiedLinkError: > /usr/lib/libjllvm.so: /usr/lib/libjllvm.so: undefined symbol: > _ZTVN10__cxxabiv120__si_class_type_infoE If I have to guess, this means that the CMake stuff given is linking to the C++ libraries

Eli Gottlieb <eligottlieb at gmail.com> writes: > So you're saying that the default CMake build of LLVM creates static > libraries that got linked into my shared-object and now require me to > link in everything they require myself? Shouldn't the linker be able > to track down C++ runtime for this? You told CMake to manage your shared library as if it were a pure C