llvm dev - Oct 2010 - [LLVMdev] [llvm-commits] Fwd: Proof of concept patch for unifying the .s/ELF emission of .ARM.attributes

> Also what is the preferred method for MC way of setting out subsection
> sizes after the fact? I am guessing I need to use an MCFixup?
> How do I get an MCExpr to evaluate a method for the subsection size?
> Is there an equivalent use in the places using MCFixup?
> Do I need to add a new subclass to MCExpr for doing this?
>
> JimG, can you please comment on the MachO specific parts in the
> ARMAsmPrinter.cpp? Is there an example of a "subsection size"
that is
> "Fixed up" after all the blobs that go into that subsection are
> emitted? The closest examples I could find weren't that close :-(
> (Matter of fact, for ELF, it looks like the section sizes are actually
> calculated after everything has been processed by MCAssembler, and the
> headers sizes are not "fixed up" but completely rewritten from
the
> beginning)
I really don't follow. Please just convert the current patch to use
the existing APIs. If in the next one you really need a missing
feature it will be a lot easier to explain what it is.
> Thanks!
>
> -jason
Cheers,
Rafael

On Thu, Oct 21, 2010 at 11:42 AM, Rafael Espíndola
<rafael.espindola at gmail.com> wrote:
>> Also what is the preferred method for MC way of setting out subsection
>> sizes after the fact? I am guessing I need to use an MCFixup?
>> How do I get an MCExpr to evaluate a method for the subsection size?
>> Is there an equivalent use in the places using MCFixup?
>> Do I need to add a new subclass to MCExpr for doing this?
>>
>> JimG, can you please comment on the MachO specific parts in the
>> ARMAsmPrinter.cpp? Is there an example of a "subsection size"
that is
>> "Fixed up" after all the blobs that go into that subsection
are
>> emitted? The closest examples I could find weren't that close :-(
>> (Matter of fact, for ELF, it looks like the section sizes are actually
>> calculated after everything has been processed by MCAssembler, and the
>> headers sizes are not "fixed up" but completely rewritten
from the
>> beginning)
>
> I really don't follow. Please just convert the current patch to use
> the existing APIs. If in the next one you really need a missing
> feature it will be a lot easier to explain what it is.
Hi Rafael.

That is exactly what I need - I need a nice MC way to output a at
least two different 4 byte size fields after all of the blobs in the
.ARM.attributes
are sent out. I am currently doing this manually by messing with the
MCDataFragment directly - (I cribbed from the ELFObjectwriter code)
The size field kind of acts like an ELF section header size field, but
trying to replicate the MCAssembler/MCLayout mechanics seemed a bit
much, and from the existing sources,
I could not find a relevant use of MCExpr/MCFixup that does this. I
even considered outputing a fake symbol, but that didn't work well
either. The code I have now was the simplest I could make it under the
constraints I found myself in. If there is a "better way" in MC to do
something like this, I'll be more than happy to do it, if just for my
own education.

Err... help?? :-)

Thanks!!

-jason
>
>> Thanks!
>>
>> -jason
>
> Cheers,
> Rafael
>

2010/10/21 Jason Kim <jasonwkim at google.com>:
> That is exactly what I need - I need a nice MC way to output a at
> least two different 4 byte size fields after all of the blobs in the
> .ARM.attributes are sent out.
Hi Jason,

If I got it right, you need to write to the attributes section after
you have moved out to print the rest of the file.

I can't think of an example right now that would require that (as you
have most important information from the IR), but I believe GAS does
that when guessing the build attributes.

What are these two word you need to write? Why can't you write them
when building the attributes section?

cheers,
--renato

On Thu, Oct 21, 2010 at 11:42 AM, Rafael Espíndola
<rafael.espindola at gmail.com> wrote:
>> Also what is the preferred method for MC way of setting out subsection
>> sizes after the fact? I am guessing I need to use an MCFixup?
>> How do I get an MCExpr to evaluate a method for the subsection size?
>> Is there an equivalent use in the places using MCFixup?
>> Do I need to add a new subclass to MCExpr for doing this?
>>
>> JimG, can you please comment on the MachO specific parts in the
>> ARMAsmPrinter.cpp? Is there an example of a "subsection size"
that is
>> "Fixed up" after all the blobs that go into that subsection
are
>> emitted? The closest examples I could find weren't that close :-(
>> (Matter of fact, for ELF, it looks like the section sizes are actually
>> calculated after everything has been processed by MCAssembler, and the
>> headers sizes are not "fixed up" but completely rewritten
from the
>> beginning)
>
> I really don't follow. Please just convert the current patch to use
> the existing APIs. If in the next one you really need a missing
> feature it will be a lot easier to explain what it is.
Hi Rafael

Included are two patches. The first one s06-mod, is the original one.
The s06-brk uses the high level Streamer interface, but currently does
not pass the test I added.

Please see the comments in the second patch. Hopefully it clarifies
the issues in using the high level MCStreamer interface in emitting
the .ARM.attributes ELF section directly.
It does not seem worthwhile to use the high level Streamer interface
for this kind of work,  so I'd very much like some feedback on what
the preferred solution is.

Thanks!
-jason
-------------- next part --------------
A non-text attachment was scrubbed...
Name: arm-mc-elf-s06-mod.patch3
Type: application/octet-stream
Size: 12692 bytes
Desc: not available
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20101022/d365cf76/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: arm-mc-elf-s06-brk.patch
Type: text/x-patch
Size: 12263 bytes
Desc: not available
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20101022/d365cf76/attachment.bin>

---------- Forwarded message ----------
From: Jason Kim <jasonwkim at google.com>
Date: Fri, Oct 22, 2010 at 12:59 PM
Subject: Re: [llvm-commits] Fwd: Proof of concept patch for unifying
the .s/ELF emission of .ARM.attributes
To: Rafael Espíndola <rafael.espindola at gmail.com>


On Fri, Oct 22, 2010 at 12:51 PM, Jason Kim <jasonwkim at google.com>
wrote:
> On Thu, Oct 21, 2010 at 11:42 AM, Rafael Espíndola
> <rafael.espindola at gmail.com> wrote:
>>> Also what is the preferred method for MC way of setting out
subsection
>>> sizes after the fact? I am guessing I need to use an MCFixup?
>>> How do I get an MCExpr to evaluate a method for the subsection
size?
>>> Is there an equivalent use in the places using MCFixup?
>>> Do I need to add a new subclass to MCExpr for doing this?
>>>
>>> JimG, can you please comment on the MachO specific parts in the
>>> ARMAsmPrinter.cpp? Is there an example of a "subsection
size" that is
>>> "Fixed up" after all the blobs that go into that
subsection are
>>> emitted? The closest examples I could find weren't that close
:-(
>>> (Matter of fact, for ELF, it looks like the section sizes are
actually
>>> calculated after everything has been processed by MCAssembler, and
the
>>> headers sizes are not "fixed up" but completely rewritten
from the
>>> beginning)
>>
>> I really don't follow. Please just convert the current patch to use
>> the existing APIs. If in the next one you really need a missing
>> feature it will be a lot easier to explain what it is.
>
> Hi Rafael
>
> Included are two patches. The first one s06-mod, is the original one.
> The s06-brk uses the high level Streamer interface, but currently does
> not pass the test I added.
>
> Please see the comments in the second patch. Hopefully it clarifies
> the issues in using the high level MCStreamer interface in emitting
> the .ARM.attributes ELF section directly.
> It does not seem worthwhile to use the high level Streamer interface
> for this kind of work,  so I'd very much like some feedback on what
> the preferred solution is.
Sigh. I sent an earlier patch by mistake for s06-brk. It does not
compile, but it should still suffice for demonstration purposes.
Sorry for the mess.
>
> Thanks!
> -jason
>

OK, after reading the docs I have some extra comments (and an updated patch).

*) To support per section or per symbol attributes we would have to
move this to the processing done in the end of the file. Lets not do
this right now.
*) We don't currently use any string attributes, so I did not implement
them.
*) Having an attribute emitter class is a nice way to separate the job
of creating the attributes and the decisions of what attributes to
use.
*) The best way I could find of avoiding code duplication was to make
getCurrentFragment and getOrCreateDataFragment public. If they must
really be protected we can then create a special ARM streamer that has
the same functionality as the attribute emitter in this patch. Yet
another option is adding a method for writing over old data in the
streamer API.
*) I added support for multiple vendors, but that is not used. I can
remove if you want.
*) Using virtual methods might be too much. Let me know if you like
OutStreamer.hasRawTextSupport better. Using the class has the
advantage of having only one cast to MCObjectStreamer.

Cheers,
Rafael
-------------- next part --------------
A non-text attachment was scrubbed...
Name: attrs.patch
Type: text/x-patch
Size: 13434 bytes
Desc: not available
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20101023/86bcdb87/attachment.bin>