similar to: [LLVMdev] R_ARM_ABS32 disassembly with integrated-as

Hi Greg, > Is this a bug? If so, how can I fix it? It's somewhere between a bug and a quality-of-implementation issue. ARM often uses literal pools in the middle of code when it needs to materialize a large constant (or variable address more likely for R_ARM_ABS32). This results in a sequence roughly like: ldr r0, special_lit_sym [...] b past_literals special_lit_sym:

On Oct 5, 2012, at 12:15 AM, Tim Northover <t.p.northover at gmail.com> wrote: > Hi Greg, > >> Is this a bug? If so, how can I fix it? > > It's somewhere between a bug and a quality-of-implementation issue. > ARM often uses literal pools in the middle of code when it needs to > materialize a large constant (or variable address more likely for >

On 5 October 2012 10:53, Kristof Beyls <kristof.beyls at arm.com> wrote: > FWIW, I believe the following bugzilla issue reports/covers that > mapping symbols are not being produced: > http://llvm.org/bugs/show_bug.cgi?id=9582 Yes.. I meant to fix that and it kinda slipped... ;) Greg, There should be information enough in the bug to be an easy fix. If you *really* don't want

I'm attempting to detect encoding bugs by comparing disassembly when using GCC's 'as' versus LLVM's integrated assembler. Generally this has gone very well, but one thing that adds a lot of noise is that .word marked as a R_ARM_ABS32 is disassembled as an instruction and not data. Please see the attached 'dump.diff' which was generated by diffing the "objdump -d

Hi Greg, I'm afraid I've not looked into the infrastructure Jim put into place, so I've not really been able to answer the "how should I do it" questions, but hopefully I can comment on the ABI. > And probably questions for Tim, are these "section-relative" mapping > symbols, as defined in 4.6.5.1 of the ELF for ARM document? Yes, they are. > And what

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)

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

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

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

Both armasm and gnu as support an ldr pseudo instruction for loading constants that lowers to either a mov, movn, or a pc-relative ldr from the constant pool. It would be great if the llvm integrated assembler could support this feature as well. For example, using gnu as to compile this code: .text foo: ldr r0, =0x1 ldr r0, =-0x1 ldr r0, =0x1000001 ldr r0, =bar

On 5 October 2012 17:48, Jim Grosbach <grosbach at apple.com> wrote: > The recent MachO data-in-code support should have fixed a lot of the problems. There's probably still some quirks in the specifics ($a vs. $t and making sure the symbols get into the ELF properly), but the core functionality to know how to mark data regions is there and works very well. Hi Jim, I'm trying to

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 Oct 10, 2012, at 12:05 PM, Renato Golin <rengolin at systemcall.org> wrote: > Thanks Jim! > > I have updated the bug with your comments, I think it's a good start. > > Greg, let me know

Thanks Jim! I have updated the bug with your comments, I think it's a good start. Greg, let me know if that's not enough, I think I can help you from now on. cheers, --renato On 9 October 2012 23:58, Jim Grosbach <grosbach at apple.com> wrote: > > On Oct 7, 2012, at 3:14 AM, Renato Golin <rengolin at systemcall.org> wrote: > >> On 5 October 2012 17:48, Jim

Attached is an example of how to reproduce the issue. It uses a C file that happens to has a bunch of switch statements which are encoded as jump tables, giving us data-in-code. Usage: To build object files with clang via the -integrated-as versus via GCC: $ export NDK_DIR=<my_ndk_dir> $ export LLVM_DIR=<my_llvm_bin_dir> $ make To test that the generated objects contain the same

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

Hi Tim, Thanks a lot for the reply. I tested libc.so which is a shared library. llvm-objdump also report some disassemble errors. Could you please tell me more about $a, $t and $d symbols? How these symbols are used to define different regions? Where I can find this symbols in ELF object file? Thanks, David I'm now try to find a decoder of ARM instructions in oder On Thu, Jun 7, 2012

On Oct 7, 2012, at 3:14 AM, Renato Golin <rengolin at systemcall.org> wrote: > On 5 October 2012 17:48, Jim Grosbach <grosbach at apple.com> wrote: >> The recent MachO data-in-code support should have fixed a lot of the problems. There's probably still some quirks in the specifics ($a vs. $t and making sure the symbols get into the ELF properly), but the core