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

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
> 
> 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 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 help Greg crack it down. From your recent
commits, I
>>> take it you're re-using a data-in-code detection previously
used only
>>> for ASM output, to object output, via the
>>> EmitDataRegion/EmitDataRegionEnd.
>>> 
>> 
>> It's a bit more than that. Those Emit* methods are new for this
support. There was spotty support for the raw $a/$t/$d stuff before, and this
abstracted and extended it to support both asm and binary emission as well as
added uses for the methods to the various bits in the ARM backend where
data-in-code regions get created (jump tables, constant pools, et. al.).
>> 
>> 
>>> I haven't looked too deep in the MC, but I'm supposing that
will work
>>> automatically when the output streamer is printing object code and
>>> meets a non-code region, so in theory, changing MCELFStreamer
>>> accordingly (overriding those functions in there) would take care
of
>>> data vs. code issue in ELF.
>> 
>> Yep. They'll likely be implemented as, effectively, an EmitLabel().
>> 
>>> Assuming LLVM doesn't generate ARM/Thumb veneers inside the
same
>>> function (ie. a Thumb function has only Thumb code), Greg could use
>>> the EmitDataRegion and EmitDataRegionEnd, with the former saving
the
>>> state of the current code (Thumb/Arm) and the latter restoring it,
by
>>> emiting the $d and $a/t respectively.
>>> 
>>> Does it seem like a good initial approach?
>>> 
>>> Continuing... It seems MCELFStreamer already has a EmitThumbFunc,
>>> which looks to me as the wrong place to be.
>> 
>> That's just the handler for the .thumb_func directive. It has
nothing to do with emitting the contents of the actual function.
>> 
>>> I'd imagine MCELFStreamer
>>> would have EmitFunc and MCARMELCStreamer (or whatever) would
identify
>>> its type and call the appropriate EmitThumbFunc/EmitARMFunc. Being
>>> pedantic, even that is still too high level because of the
ARM/Thumb
>>> veneers, but we don't want to worry about that if LLVM
doesn't even
>>> try to mix ARM and Thumb (and assuming external libraries would
have
>>> the symbols, if they do).
>> 
>> This is complicated a bit by needing to work for plain .s files, not
just compiler generated files. Those can intermix arm and thumb code in crazy
ways.
>> 
>> The assembler already has a thumb vs. arm mode state (which gets
adjusted via the .arm/.thumb directives and the .code synonyms). ELF will want
to check that state and use it to determine whether a data-region-end directive
should result in a $a or a $t in the output ELF.
>> 
>>> Generating or not, LLVM's disassembler should know about those
symbols
>>> and should be able to mark them accordingly. Where would be the
best
>>> part to put those symbols (in an enum or table), so that the
>>> MCStreamer and the disassembler could reference a single place?
>> 
>> It's not the disassembler itself that should know about them, but
the driver for the disassembler. In this case, llvm-objdump. The disassembler
doesn't have that kind of gestalt knowledge.
>> 
>> -Jim
>> 
>> 
>>> 
>>> --
>>> cheers,
>>> --renato
>>> 
>>> http://systemcall.org/
>> 
> 
> 
> 
> -- 
> cheers,
> --renato
> 
> http://systemcall.org/

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

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>