search for: enhanceddisassembly

Current llvm svn at r136461 is failing to bootstrap under darwin11 with... cd /sw/src/fink.build/llvm30-3.0-0/llvm-3.0/build/tools/edis && /sw/bin/cmake -E cmake_link_script CMakeFiles/EnhancedDisassembly.dir/link.txt --verbose=1 /sw/var/lib/fink/path-prefix-clang/c++ -fPIC -fno-rtti -O3 -DNDEBUG -shared -L/sw/lib -o ../../lib/libEnhancedDisassembly.dylib -install_name /sw/src/fink.build/llvm30-3.0-0/llvm-3.0/build/lib/libEnhancedDisassembly.dylib CMakeFiles/EnhancedDisassembly.dir/EDMain.cpp.o...

...smLexers for ARM and Thumb. They are shallow subclasses of a common tokenizer that uses a std::map of register names to IDs to recognize register names, and reports those as AsmToken::Register tokens instead of identifiers. I intend to use the ARM and Thumb AsmLexers as part of an extension of the EnhancedDisassembly library, which provides tokenization and interpretation functions on top of the basic disassembler, to ARM. Please let me know what you think of this patch. Sean -------------- next part -------------- A non-text attachment was scrubbed... Name: arm-asm-lexer.diff Type: application/octet-stream S...

...> I guess what I think needs a bit more explanation is why you chose to > go the "markup" route, instead of a normal programmatic API. To keep the surface area of the C API as minimal as possible and robust against changes in what's marked up and how. Consider the interface in EnhancedDisassembly.h, for an example of what we specifically want to avoid (and obsolete). > Maybe you > could also include a couple use cases that capture your "vision" for > this functionality, and maybe a tiny bit of sample code doing > something interesting with a very rough initial interfa...

...needs a bit more explanation is why you chose to >>> go the "markup" route, instead of a normal programmatic API. >> >> To keep the surface area of the C API as minimal as possible and robust against changes in what's marked up and how. Consider the interface in EnhancedDisassembly.h, for an example of what we specifically want to avoid (and obsolete). >> >>> Maybe you >>> could also include a couple use cases that capture your "vision" for >>> this functionality, and maybe a tiny bit of sample code doing >>> something inte...

...what I think needs a bit more explanation is why you chose to >> go the "markup" route, instead of a normal programmatic API. > > To keep the surface area of the C API as minimal as possible and robust against changes in what's marked up and how. Consider the interface in EnhancedDisassembly.h, for an example of what we specifically want to avoid (and obsolete). > >> Maybe you >> could also include a couple use cases that capture your "vision" for >> this functionality, and maybe a tiny bit of sample code doing >> something interesting with a very r...

...h PassSupport.h ValueSymbolTable.h CallGraphSCCPass.h GlobalAlias.h Intrinsics.td MC/ Support/ aarumug at aarumgxp /cygdrive/c/llvm-2.8/include/llvm $ cd ../llvm-c aarumug at aarumgxp /cygdrive/c/llvm-2.8/include/llvm-c $ ls Analysis.h BitWriter.h EnhancedDisassembly.h LinkTimeOptimizer.h Transforms/ BitReader.h Core.h ExecutionEngine.h Target.h lto.h -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20110209/70f4672a/attachment.html>

...t more explanation is why you chose to >>>> go the "markup" route, instead of a normal programmatic API. >>> >>> To keep the surface area of the C API as minimal as possible and robust against changes in what's marked up and how. Consider the interface in EnhancedDisassembly.h, for an example of what we specifically want to avoid (and obsolete). >>> >>>> Maybe you >>>> could also include a couple use cases that capture your "vision" for >>>> this functionality, and maybe a tiny bit of sample code doing >>>...

...ike to fill out the implementation to cover the entirety of the C interface. Since this will require a lot of work (Core.h is *massive*), I wanted to run things by the community before I invest too much time and create something people don't want (I already had to back out the Python binding to EnhancedDisassembly because I didn't realize it was deprecated - oops). Are people interested in more expansive in-tree Python bindings? Specifically, do we want a Python API for the IR primitives like type and value that sit lower than the module APIs? I know there are other Python bindings floating around and...

...nation is why you chose to >>>>> go the "markup" route, instead of a normal programmatic API. >>>> >>>> To keep the surface area of the C API as minimal as possible and robust against changes in what's marked up and how. Consider the interface in EnhancedDisassembly.h, for an example of what we specifically want to avoid (and obsolete). >>>> >>>>> Maybe you >>>>> could also include a couple use cases that capture your "vision" for >>>>> this functionality, and maybe a tiny bit of sample code do...

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

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

.../llvm-c -- Installing: /usr/local/llvm-2.8/include/llvm-c/Analysis.h -- Installing: /usr/local/llvm-2.8/include/llvm-c/BitReader.h -- Installing: /usr/local/llvm-2.8/include/llvm-c/BitWriter.h -- Installing: /usr/local/llvm-2.8/include/llvm-c/Core.h -- Installing: /usr/local/llvm-2.8/include/llvm-c/EnhancedDisassembly.h -- Installing: /usr/local/llvm-2.8/include/llvm-c/ExecutionEngine.h -- Installing: /usr/local/llvm-2.8/include/llvm-c/LinkTimeOptimizer.h -- Installing: /usr/local/llvm-2.8/include/llvm-c/Target.h -- Installing: /usr/local/llvm-2.8/include/llvm-c/Transforms -- Installing: /usr/local/llvm-2.8/incl...

On Thu, Sep 30, 2010 at 3:08 PM, Samuel Williams <space.ship.traveller at gmail.com> wrote: > Hi, > > I might just be doing something stupid, but when I do > > $ cmake -DCMAKE_INSTALL_PREFIX=/usr/local/llvm-2.8 -DCMAKE_BUILD_TYPE=Release .. > $ sudo make install > > I don't get the expected headers in >        /usr/local/llvm-2.8/include/llvm > > It is

Hi, I might just be doing something stupid, but when I do $ cmake -DCMAKE_INSTALL_PREFIX=/usr/local/llvm-2.8 -DCMAKE_BUILD_TYPE=Release .. $ sudo make install I don't get the expected headers in /usr/local/llvm-2.8/include/llvm It is simply an empty directory. What am I doing wrong? This is on Mac OS X, CMake 2.8+ Kind regards, Samuel