[LLVMdev] writeNopData and non-instructions in .text

[David Majnemer]

On Tue, Sep 16, 2014 at 10:46 PM, Joerg Sonnenberger <
joerg at britannica.bec.de> wrote:

> Hi all,
> all ELF platforms at least and likely all others too allow something
> like the following:
>
>     .text
>     .asciz "arbitrary long string"
>     .p2align 3
>
> Depending on the size of the string, MCAsmBackend::writeNopData is
> called to pad text. For x86 and other backends with byte-sized
> instructions, this is no problem. Some backends like ARM and PPC
> flush explicitly to 16bit/32bit boundaries. There is an interested
> question on whether the non-instructions should be leading or trailing
> -- I think the behavior in ARM and PPC is wrong in this regard.


I am pretty sure I implemented the PowerPC behavior in r191426.

I would be in favor of the following:
1. If the start is aligned *and* the length is aligned, use nops.
2. If the start is aligned but the length is not aligned, insert as many
nops possible but pad out with zero.
3. Otherwise (if the start is misaligned), use *just* zeros.

The R600
> backend seems to be just broken by not writing anything. This leaves
> SPARC and Mips. Both currently just return false if the padding is not a
> multiply of 32bit and the caller just reports an error.
>
> All this makes me wonder:
> (1) Why do we allow the backend to fail at all? Shouldn't the
> "pad-with-0" or so behavior be the default?
> (2) What is the expected order? Pad to instruction size first or last?
>
> Joerg
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140916/6bf04575/attachment.html>