similar to: Problems using LLVM as a disassembler.

Hello Tim, Rafael, Renato and llvmdev, I’m working to get llvm-objdump handle both arm and thumb disassembly from the same object file similarly to how darwin’s otool(1) works. And I’m looking for implementing direction. I spoke to Jim Grosbach about some ideas and he suggested I send out and email about some of the possibilities. Since none of the ones I could think of are pretty he thought

llvm-dev, Thanks so much in advance for any help, tips, or advice you may be able to offer me. I'm going to try to avoid the big-picture description of the project I'm working on, and only talk about the parts that I have trouble with / currently need to implement. -- I've been starting by taking the source code from the "llvm-mc" tool, and working that down into a

Hi, My apologies if this appears to be a very trivial question -- I have tried to solve this on my own and I am stuck. Any assistance that could be provided would be immensely appreciated. What is the absolute bare minimum that I need to do to disassemble an array of, say, ARM machine code bytes? Or an array of Thumb machine code bytes? For example, I might have an array of unsigned chars -- how

Hi Aiden, The easiest thing I can do is to point you to the source of the "llvm-mc" tool, which does exactly what you ask in its "-disassemble" mode. The code is rather small, so it should be easy to work out. tools/llvm-mc Cheers, James -----Original Message----- From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Aidan Steele Sent:

Hi Aiden, The 'C' based interface you could use in is llvm/include/llvm-c/Disassembler.h, which in there is: /** * Disassemble a single instruction using the disassembler context specified in * the parameter DC. The bytes of the instruction are specified in the * parameter Bytes, and contains at least BytesSize number of bytes. The * instruction is at the address specified by the

Hi Kev and James, Thanks to both of you for responding. I had looked at the otool release published for 10.7.2 (cctools-800), but it seems that it only snuck in after that and by the cctools-809 release! In any case, both that and llvm-mc should be more than adequate! A follow-up question: is the C interface to LLVM a second-class citizen or should I reasonably be able to expect to do everything

On Wed, Oct 12, 2011 at 3:17 AM, Songmao <smtian at ingenic.cn> wrote: > Michael, >    I have rework the patch according to your suggestion.  And I have read > binutil/objdump source code and found that it has a logic that if there's no > symtab, it will use dynsym, which is missing in llvm-objdump. > > Songmao > @@ -747,12 +747,28 @@ error_code

On Aug 19, 2009, at 4:39 PM, Sean Callanan wrote: > thanks for your comments. I'll respond to them individually. I've > attached a new revision of the patch that addresses them. Patch > built and tested against SVN 79487, with the additional attached fix > that fixes an Intel table bug. Thanks Sean, comments below. Are you sure you attached the updated patch? I

Hi, I'm embarrassed that I can't figure this out... I have a compiler that outputs my module in either .s assembly format or .obj binary format, either one works just fine. But if I try to output both of them by adding passes, LLVM throws an Assert: void WinCOFFStreamer::EmitLabel(MCSymbol *Symbol) { assert(Symbol->isUndefined() && "Cannot define a symbol

Hi James, On Aug 12, 2011, at 1:02 AM, James Molloy wrote: > I’ve got a load of examples for this, but I’ll pick one. > > echo '0xB0 0x00 0x00 0x00' |/work/llvm-cmake2/build/bin/llvm-mc -arch arm --disassemble – > strheq r0, [r0], -r0 > > This instruction encoding is marked UNPREDICTABLE. The question is: does a disassembly of it have value? One use case put

Hi all. I fully understand that the problem is a bit OT for llvmdev, but I'm stuck for two days now and I really need some direct push. To the problem. I have a C++ shared library, that's working with llvm C++ api. Consider a function: static Object llvm_Target_createMCAsmInfo(Object self, Object tripleName) { llvm::Target target = from_ruby<llvm::Target>(self); char const

On 23 May 2015 at 00:08, Jim Grosbach <grosbach at apple.com> wrote: > This is the key question. The LLVM assumption is that these sorts of things > are inferable from the triple. Your observation here that the GNU world’s > notion of triples and LLVM’s need not be the same is a good one. Having a > split and a translation up in clang seems an interesting avenue to explore. >

Llvm typically doesn't build with RTTI enabled. Perhaps that's what you're running into? Jim On Dec 10, 2012, at 1:27 PM, Vladimir Pouzanov <farcaller at gmail.com> wrote: > Hi all. > > I fully understand that the problem is a bit OT for llvmdev, but I'm stuck for two days now and I really need some direct push. > > To the problem. I have a C++ shared

I can't reproduce the more complex version. But the package on CRAN fails in the same way on 3.2.3 and 3.3.0. The problem is that your sysdata.rda includes a function that is generating this error. If you do f <- getFromNamespace(".RMXE", ns ="RobAStRDA")[["GEVFamily"]][["fun.N"]][[1]] g <- get("fct", environment(f)) and look at the

Hello, My question in 2 words is the following: Is it mandatory to generate host keys on the target host, or can they be generated on another host and transfer to thetarget host ? If my question is not clear here is an example... I need to install host keys on a host server. I imagine the usual way is to launch the following command locally on the host server . # ssh-keygen -t rsa1

Michael, I have rework the patch according to your suggestion. And I have read binutil/objdump source code and found that it has a logic that if there's no symtab, it will use dynsym, which is missing in llvm-objdump. Songmao -------------- next part -------------- A non-text attachment was scrubbed... Name: 0002-Fix-the-address-calculation-for-llvm-objdump.patch Type: text/x-patch

Owen, As I recall, we had some similar issues with custom decoders needing to cooperate on ARM. Do you remember the details? -Jim On Dec 18, 2012, at 2:37 AM, Richard Osborne <richard at xmos.com> wrote: > I'm currently trying to get llvm-mc --disassemble working for the XCore backend. Up until recently there was no instruction encoding / decoding information on any of the XCore

Hi. I have strange case: This is a code for getting metadata from callsite: .... CallSite CS(cast<Value>(I->first)); SmallVector<std::pair<unsigned int, MDNode*> , 4> MD; CS.getInstruction()->getAllMetadata(MD); CS.getInstruction()->dump(); for (SmallVector<std::pair<unsigned int, MDNode*> , 4>::iterator md = MD.begin(); md!=MD.end(); md++)

I'm currently trying to get llvm-mc --disassemble working for the XCore backend. Up until recently there was no instruction encoding / decoding information on any of the XCore instructions so Im incrementally adding this information at the same time as adding tests for the disassembler. However I've run into a problem and I'm not sure of the best way to solve it. With some of the