On Tue, Jun 14, 2016 at 12:43 PM, Jim Wilson jim.wilson@linaro.org wrote:

I can reproduce with an FSF binutils. Not obvious why it is failing though.

A git bisect tracks the problem down to this commit.

palantir:2177$ git bisect bad c1baaddf8861aea666b84baeb4746caff51a579d is the first bad commit commit c1baaddf8861aea666b84baeb4746caff51a579d Author: Renlin Li renlin.li@arm.com Date: Thu Apr 2 14:59:45 2015 +0100

[AArch64] Emit DATA_MAP in order within text section

2015-03-27 Renlin Li renlin.li@arm.com

gas/ * config/tc-aarch64.c (mapping_state): Emit MAP_DATA within text section in order. (mapping_state_2): Don't emit MAP_DATA here. (s_aarch64_inst): Align frag during state transition. (md_assemble): Likewise.

:040000 040000 513292511d3717bb5d8fa7f3227e5eb352025a02 06d2298d935ea4d0698c7dbf2b713e2dc290f498 M gas palantir:2178$

The problem here is with the md_assemble change, which is calling frag_align_code inside a loop, which means it can emit multiple alignment frags with a single call. We are not in the text section, which means we always get this alignment frag. These alignment frags have variable size, and hence the .if test on dot no longer works.

This patch isn't present in the binutils-2.25 that tcwg is using. The patch is present in binutils-2.26.

I've never looked at this MAP_DATA support, so the solution is not immediately obvious to me.

Testcase attached.

Jim

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,