similar to: [LLVMdev] typeinfo for llvm::MCAsmInfo is missing

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've actually tried to compile both LLVM and my lib with -frtti with same results. On Dec 10, 2012, at 21:57, Jim Grosbach <grosbach at apple.com> wrote: > Llvm typically doesn't build with RTTI enabled. Perhaps that's what you're running into? > > Jim -- Vladimir Pouzanov http://www.farcaller.net/ -------------- next part -------------- A non-text attachment

Vladimir Pouzanov <farcaller at gmail.com> writes: > On Dec 10, 2012, at 21:57, Jim Grosbach <grosbach at apple.com> wrote: >> Llvm typically doesn't build with RTTI enabled. Perhaps that's what >> you're running into? >> > I've actually tried to compile both LLVM and my lib with -frtti with > same results. Please show the exact commands

Hi all. I'm looking for some way to do code analysis with LLVM. Can someone please give me a hint, if it is possible to query an MCInst for what are input operands and what are output operands? Small example. Consider we have an instruction: str r1, [sp, #8] Being mapped into MCInst instance it has the following operands: <MCOperand Reg:61> <-- maps to reg r1

Hi all. I came across a strange behaviour in the instruction printer for Thumbv2: The instruction is 0xf000b800, which is a b.w #0 LLVM returns it as b.w #-262144, which doesn't make any sense to me. Should I consider it a bug? -- Vladimir Pouzanov http://www.farcaller.net/

Yep, b.w using ARM's "alternative syntax" is broken. Luckily, though LLVM bitcode doesn't compile to this form, and will always use a label instead. Here's a patch that only acknowledges the broken instructions: https://github.com/garious/llvm/commit/916c4badd816178da9fdbac5b5ed2331a7201f98 I submitted this to llvm-commits a while back, but nobody replied. :( -Greg

Ah, sometimes things get lost. How about resubmitting the patch and cc'ing me and grosbach at apple.com? Thanks! -eric On Thu, Dec 27, 2012 at 5:17 PM, Greg Fitzgerald <garious at gmail.com> wrote: > Yep, b.w using ARM's "alternative syntax" is broken. Luckily, though LLVM > bitcode doesn't compile to this form, and will always use a label instead. >

Hi all. I'm investigating an issue with incorrect lldb's disassembly output. I have two bytes in question: 4e5f lldb (via the llvm's LLVMARMCodeGen) is providing the following mnemonics: ldr r6, #380, However the value for ldr is "an 8-bit value that is multiplied by 4 and added to the value of the PC to form the memory address" (via ARMARM), so that the correct

Good. Copying llvmdev for the record. Vladimir Pouzanov <farcaller at gmail.com> writes: > Sorted it out. > > In the end, the working build commands for me were: > > % export CXXFLAGS=-frtti > % ../llvm-3.1/configure > --prefix=/Users/farcaller/Developer/Active/llvm-src/install-3.1 > --enable-debug-runtime --enable-debug-symbols --disable-docs > --disable-doxygen

> -----Original Message----- > From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] > On Behalf Of Óscar Fuentes > > Vladimir Pouzanov <farcaller at gmail.com> writes: > > > On Dec 10, 2012, at 21:57, Jim Grosbach <grosbach at apple.com> wrote: > >> Llvm typically doesn't build with RTTI enabled. Perhaps that's what

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

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. >

Hi, Am Mittwoch, 26. Dezember 2012, 15:20:27 schrieb Manny Ko: > The MCInstrDesc has a method getNumDefs() which tells you how many 'out > registers' that MCInst has. The 'out' registers are always at the beginning > of the list. You can also use getNumOperands(). I've run into the problem, that this doesn't work for instructions which have variadic arguments

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

Hi everybody, I would like to use ruby2ruby in a caming project, but there seems to be an incompatibility with camping, ruby2ruby and markaby. Unfortunately I receive strange Markaby::InvalidXhtmlErrors. To demonstrate, that only combination of all three components causes the problem I added the following code. I relies on Markaby and ruby2ruby only and works fine (a.k.a. as expected).

The MCInstrDesc has a method getNumDefs() which tells you how many 'out registers' that MCInst has. The 'out' registers are always at the beginning of the list. You can also use getNumOperands(). Not sure if this is what you are looking for. -----Original Message----- From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Vladimir Pouzanov

Hi! I can''t run fxruby setup on FreeBSD 6 (amd64, 2x opteron) I had no problems with Fox ./configure --with-shape --enable-threadsafe --enable-cups \ --with-x --with-xft --with-xcursor --with-xrandr --with-xim \ --with-profiling --with-opengl && make && make install but I get errors when I try to setup fxruby: (config shows no errors) ruby install.rb config -- \

Gordon Keiser <gkeiser at arxan.com> writes: > There is (was?) a CMake variable for this if you're going that route. > Setting LLVM_REQUIRES_RTTI=1 enabled an RTTI build that I haven't had > issues with. I don't know what the ./configure equivalent is, sorry. LLVM_REQUIRES_RTTI is an internal variable. It works as you say, but there is no guarantee about it. Adding a

Hi, I have been trying to use LLVM as a disassembler, thus providing a small part of my decompiler that I am working on. It currently decompiles from X86_64 binary.o -> LLVM IR. It works with a small set of test programs so far, so cannot currently handle large binary programs yet. The problem is with the LLVM "getInstruction()" method. It used to have a PC (program counter)