llvm dev - Oct 2012 - [LLVMdev] R_ARM_ABS32 disassembly with integrated-as

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 ELF for ARM document?  And what to
put in the alignment field?  I see GCC outputting 1, 3, 4, but I don't see
a description of that field in the doc.

Lastly, from MCELFStreamer, how do I determine if we generating an ARM or
Thumb ELF?  I can catch Thumb from the EmitThumbFunc, but that seems a
little odd.  Suggestions?

Here's what I have so far:

$ readelf -s via-llvm-as.o | grep "\$."
     2: 00000000     0 NOTYPE  LOCAL  DEFAULT    4 $d
     3: 00000000     0 NOTYPE  LOCAL  DEFAULT    4 $t
 $ readelf -s via-gcc-as.o | grep "\$."
     5: 00000000     0 NOTYPE  LOCAL  DEFAULT    1 $t
    15: 0000020c     0 NOTYPE  LOCAL  DEFAULT    1 $d
    17: 00000218     0 NOTYPE  LOCAL  DEFAULT    1 $t
    44: 00000732     0 NOTYPE  LOCAL  DEFAULT    1 $d
    45: 0000073e     0 NOTYPE  LOCAL  DEFAULT    1 $t
    65: 00000000     0 NOTYPE  LOCAL  DEFAULT    4 $d
    66: 00000000     0 NOTYPE  LOCAL  DEFAULT    3 $d

Thanks,
Greg


On Wed, Oct 10, 2012 at 1:08 PM, Greg Fitzgerald <garious at gmail.com>
wrote:
> 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 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 if that's not enough, I think I can help you
from now
> on.
> >>
> >> cheers,
> >> --renato
> >>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20121015/a25e77ea/attachment.html>

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 to put in the alignment field?  I see GCC outputting 1, 3, 4, but
I don't see a
> description of that field in the doc.
I don't think individual symbols have an alignment in ELF (except
COMMON ones, which repurpose the st_value field -- not the case here).
If the 1, 3, 4 are coming from the last column of the dumps you
produced below, they're referring to the section the symbol is
relative to (st_shndx in the documentation).

Cheers.

Tim.

Jim, can you help me out with the implementation details here?  How do
I set the Value of the MCSymbolData to the address of the data region?

Per Tim's comments, here's what I have so far:

void MCELFStreamer::EmitMappingSymbol(StringRef Name) {
  MCSymbol *Symbol = getContext().GetOrCreateSymbol(Name);
  MCSymbolData &SD = getAssembler().getOrCreateSymbolData(*Symbol);
  MCELF::SetType(SD, ELF::STT_NOTYPE);
  MCELF::SetBinding(SD, ELF::STB_LOCAL);
  SD.setExternal(false);
  Symbol->setSection(*getCurrentSection());
}

...
EmitMappingSymbol("$d");

Thanks,
Greg


On Tue, Oct 16, 2012 at 1:36 AM, Tim Northover <t.p.northover at
gmail.com> wrote:
>
> 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 to put in the alignment field?  I see GCC outputting 1, 3, 4,
but I don't see a
> > description of that field in the doc.
>
> I don't think individual symbols have an alignment in ELF (except
> COMMON ones, which repurpose the st_value field -- not the case here).
> If the 1, 3, 4 are coming from the last column of the dumps you
> produced below, they're referring to the section the symbol is
> relative to (st_shndx in the documentation).
>
> Cheers.
>
> Tim.

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/

> 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?
I *think* he's comparing the same assembly in both cases: in effect
"clang -integrated-as" vs. "clang". I'm basing this on
the names of
his previous attachments: "llvm-via-gcc.dump" and
"llvm-via-integrated-as.dump".

And I'd trust LLVM to emit the constant pools it had decided on,
otherwise things would have gone horribly wrong long before mapping
symbols became an issue to anyone.

As you say, it looks like there are some missing, but that should be
reasonably easy and local to fix once we know how to find out what
needs emitting.

Tim.

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>