.align may cause data to be interpreted as instructions

[Måns Rullgård]

Taras Kondratiuk <taras.kondratiuk at linaro.org> writes:

> On 10/16/2013 10:25 PM, Dave Martin wrote:
>> Unfortunately, objdump can and does get confused about data/instruction
>> boundaries, so the output you see above may be misleading.
>> 
>> Displaying the symbol table with --special-syms will list the magic
>> symbols that mark the instruction and data boundaries, to help debug
>> this kind of situation.
>> 
>> 
>> However, in this case, I think you've found a bug in the assembler,
>> as shown below.
>> 
>> Before linking, the final $a symbol (indicating the start of ARM
>> instructions) is at address 8, so in this case objdump is correct
>> to show 0x12345678 as an instruction.
>> 
>> After linking, the mapping symbols ($[atd]) remain as before, and
>> the linker has byteswapped this "instruction" (as it should).
>> 
>> This is likely related to the magic for inserting the extensible
>> NOP-padding fragment which implements the .align in code sections.
>> That is code, and requires a $a mapping symbol, but that somehow
>> goes AWOL or gets displaced after the alignment padding ...
>> 
>> I can't quite get my head around what is going on in
>> binutils/gas/config/tc-arm.c.  We would need to understand that
>> before we can identify a reliable workaround.
>
> Thanks for confirming the issue.
> Does it makes sense to file a GCC bug?

It seems like a binutils (gas) bug to me.

-- 
Måns Rullgård
mans at mansr.com