similar to: [LLVMdev] Disassembly broken?

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

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

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

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

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

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

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

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

On 17 October 2012 22:23, Greg Fitzgerald <garious at gmail.com> wrote: > I had to move MCELF.h to "include/llvm/MC" and added a > MCELFStreamer.h to the same directory. That okay to do? This is not a trivial question, and I'll let others chip in. Superficially, you'd think so and it might make sense in the long run, but you have to consider why it wasn't there

On 17 October 2012 15:05, Greg Fitzgerald <garious at gmail.com> wrote: > + virtual void EmitMappingSymbol(bool IsData); I'd use an enum, or have multiple internal implementations... EmitDataMappingSymbol -> { nop on base class, on ARM, prints "$d" } EmitCodeMappingSymbol -> { nop on base class, calling either EmitThumbMappingSymbol or EmitARMMappingSymbol (private)

I ran into a bug in this patch. The mapping symbol produced is aligned and it should not be. Is there a way to configure the MCSymbolRefExpr such that the emitted symbol is unaligned? Alternatively, should the ARM/Thumb code be realigned after a data-in-code section? I notice that GCC leaves it unaligned. Thanks, Greg On Wed, Oct 17, 2012 at 2:32 PM, Renato Golin <rengolin at

Thanks Renato. I'm finishing up a patch for this and will post it to llvm-commits. But one concern, to create an ARMELFStreamer as you recommend, I had to move MCELF.h to "include/llvm/MC" and added a MCELFStreamer.h to the same directory. That okay to do? -Greg On Wed, Oct 17, 2012 at 7:22 AM, Renato Golin <rengolin at systemcall.org>wrote: > On 17 October 2012

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

Getting closer... When emitting symbols, how do I set the symbol's value to the address of the current instruction? Do I need to emit a label in the current section and another that uses the former to point to the latter? If possible, a code sample would be very helpful. And probably questions for Tim, are these "section-relative" mapping symbols, as defined in 4.6.5.1 of the

Great, thanks for your help. I'll take a crack at it and contact Renato if I have questions. -Greg On Wed, Oct 10, 2012 at 1:05 PM, Jim Grosbach <grosbach at apple.com> wrote: > Cool; glad to help. > > When I added the data region bits, I tried to keep the ARM-style annotations in mind a bit, so hopefully things will fit together without too much trouble. > > -Jim >

On 16 October 2012 03:16, Greg Fitzgerald <garious at gmail.com> wrote: > Lastly, from MCELFStreamer, how do I determine if we generating an ARM or > Thumb ELF? That was the only part I didn't know how to get. Jim should know. > I can catch Thumb from the EmitThumbFunc, but that seems a > little odd. Ignore EmitThumbFunc, it has nothing to do with your change. > $

Hi Jim, The diff below is not intended to be a patch, but a starting point. It is the shortest path (I hope) to getting LLVM to emit ARM mapping symbols to the ELF without changing any shared interfaces. Could you have a look at the FIXME comments and offer some pointers on how to get this code out of MCELFStreamer? Thanks, Greg diff --git a/lib/MC/MCELFStreamer.cpp b/lib/MC/MCELFStreamer.cpp