[LLVMdev] R_ARM_ABS32 disassembly with integrated-as

[Greg Fitzgerald]

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 Mapping Symbols:

$ make test

If "make test" fails, a diff is printed containing what GCC generates
versus LLVM.

To bypass clang and gcc (say you don't want to install the NDK), you
can build the same LLVM object file with just:

$ make ll

To bypass llc, you can try "make asm" to first generate a .s and then
compile that.  But if you do this, one runs into two more bugs.
First, the MC layer fails to parse ARM ELF, only MachO.  Second, clang
fails to care, bypassing the integrated-as and instead generating the
.o via GCC.  If you happen to have -ccc-gcc-name set, you will think
your test passes when what actually happened is that both objects were
compiled with GCC!

Thanks,
Greg

On Tue, Oct 16, 2012 at 1:03 PM, Renato Golin <rengolin at systemcall.org> wrote:
> 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.
>
>
>> $ readelf -s via-llvm-as.o | grep "\$."
>>      2: 00000000     0 NOTYPE  LOCAL  DEFAULT    4 $d
>>      3: 00000000     0 NOTYPE  LOCAL  DEFAULT    4 $t
>
> Clearly, you're not detecting all code/data changes, or the direct ELF
> emission is not creating too many constant pools.
>
> Can you attach the assembly generated and the ELF object created from
> both the inline asm and the gcc asm?
>
>
> --
> cheers,
> --renato
>
> http://systemcall.org/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: scaffold.C
Type: text/x-csrc
Size: 20949 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20121016/b4d2ef22/attachment.c>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: tsthd.h
Type: text/x-chdr
Size: 3291 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20121016/b4d2ef22/attachment.h>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: scaffold-arm.ll
Type: application/octet-stream
Size: 46328 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20121016/b4d2ef22/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Makefile
Type: application/octet-stream
Size: 1802 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20121016/b4d2ef22/attachment-0001.obj>