similar to: [LLVMdev] Disassembly broken for thumb LDR

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

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

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

Thank you for your help Tom you are totally right with the registers but the command you suggest also doesn't work. After some research I found the following thread on the mailing list: http://lists.llvm.org/pipermail/llvm-dev/2017-February/110086.html With your help and the information about the condition codes I was able to resolve the error:         BuildMI(BB, BB.end(), DL,

In the example provided: // InstrItinData<IIC_iLoad_i , [InstrStage<1, [A9_Pipe1]>, // InstrStage<1, [A9_AGU]>], // [3, 1], [A9_LdBypass]>, If there is an operand dependency, does the scheduler assume that the instruction is held in A9_Pipe1 or in A9_AGU until the operand is ready? Thanks again, Hal On Fri,

Martin Storsjo wrote: > This is required in order to build using the built-in assembler > in clang. These patches break the gcc build (with "Error: bad instruction"). Documentation I've seen is contradictory on which order ({cond}{size} or {size}{cond}) is correct. If clang really does require the latter, then the arm2gnu.pl translation script will need to be updated

>> Do the ARM usages include allowing a single pseudo-instruction to expand >> to multiple real instructions? For example, a movw/movt pair? If so, I’m >> *very* opposed to that part. > > > Why? For people writing assembly manually, having pseudo instructions to > encapsulate common patterns is very useful. Would it be acceptable for this pseudo-instruction to

Hi David, > 8. Check that an error is issued when the constant pool would be placed too > far away I'd say this one is actually the most involved constraint but there don't actually seem to be any tests in the attached file for it. And I believe the directive Jim's referring to is ".ltorg". It's presumably going to have some interesting quirks of its own.

> > I was thinking that without the .ltorg directive the constant pool > > would go at the end of the section. > > > So where does the assembler place the constant pool(s) if that directive > isn't present? I was under the impression it was always required. >From my understanding it is not required. I see that GCC will place it at the end of the section. I don't

On 03/22/2018 09:29 AM, Julius Hiller via llvm-dev wrote: > Hello everyone, > > I'm working on a MachineFunctionPass that inserts a list of instructions into an Module so a later Pass can work on them. > To do so I load a dummy .ll file created from a main stub, create the needed function stubs (ModulePass), insert Blocks and create instructions using BuildMI. > I started with

> I put the test in a separate file and forgot to attach it earlier. I've > attached it to this email. The ".space" directive could be very useful in making the test more manageable. Other than that I'd be wary of instructions that might be relaxed during object emission and suddenly make a load out of range. LLVM seems to do this for Bcc, pc-relative loads, ADR and B.