Hi Jim,
On 06/15/2016 05:34 AM, Jim Wilson wrote:
A few more comments...
The MAP_DATA support is emitting mapping symbols documented in the AARCH64 ELF ABI. Mapping symbols are emitted when switching from data to instructions, or vice versa, inside a section. However, mapping symbols are just addresses. There should be no need to emit implicit alignment directives before padding symbols. When switching between data and instructions, it should be the responsibility of the programmer or compiler to emit any necessary alignment directives.
The testcase is using e.g. ".align 11, 0". This specifies that the padding will be data bytes of 0, instead of perhaps a nop instruction. Since we are explicitly emitting data into a text section, this forces a switch when we emit the first instruction, which then forces an implicit alignment directive. if the code uses ".align 11" instead, then the assembler will pad with nop instructions (or maybe zeros), and there is no following switch from data mode to instruction mode.
The code to emit the implicit alignment directives is checking for a .text section. It should be checking for a section of any name that contains code instead. That eliminates unnecessary implicit alignment directives emitted in non-text text sections, like in the example which has a text section called .vectors.
I didn't try the first solution, as it isn't obvious why the apparently unnecessary implicit alignment directives are being emitted. If this padding is necessary for some obscure reason, then removing it would break something.
I did try solutions 2+3, and used together they allow the testcase to work. Patches attached.
Thanks for this cool investigation. I hope this will get fixed in the FSF builds ultimately -- either through your patches or through a future merge with the Linaro toolchain, which is unaffected.
For now, ARM-TF upstream will keep the padding value, i.e., ".align 11, 0" rather than ".align 11", because it makes the code more robust. They're using a Linaro toolchain.
As far as I'm concerned, I will either apply the workaround or switch to a Linaro toolchain.
Thanks,