armasm bug for referencing data from text section


  • While working with armasm for Windows RT I noticed that I'm getting wrong results for data declared in executable section.

    Below is a sample code. Since on Windows RT 32-bit ARM is broken and only Thumb2 works, I get unaligned fault when reading from test_data. The reason for that is because ldr r12 loads address of test_data as if it was a function (e.g. it adds 1 to the address). In armasm from arm.com there are directives to control that behavior: functions need to marked as functions so that likner would know that it needs to patch the addresses to make them thumb. For data it doesn't add 1, but the armasm from microsoft seems to ignore everything and tread it as thumb function anyways. Also, I wasn't able to force the address to be propelry aligned for reads with ldr   r12, =test_data^1 (armasm gives a error for this).

    ALIGN 4 test_data DCD 0 //repeat it 7 more times 6 times

    test LDR r12,=test_data VLD1.64 {d12,d13,d14,d15},[r12@128] BX lr

    Wednesday, October 30, 2013 9:35 PM

All replies

  • Thumb2 and the Windows Runtime ABI are required. Windows RT always sets the CPU into Thumb2 mode and into low-endian mode. You cannot write just a code stub without providing a function interface matching the calling convention the compiler expects.

    I've taken a note that we need clearer documentation on this.


    Wednesday, October 30, 2013 10:11 PM
  • in this sample it has nothing to do with abi or calling convention.

    Imagine that the bytes of the test_data are located at 0x1234000

    This line loads address of test_data into r12. E.g. r12 should now contain: 0x12340000

    LDR      r12,=test_data

    What I'm saying is that because of bugs in the tools r12 will actually contain this value:


    that's the proper behavior on arm if test_data was a function in thumb mode. However, that behavior shouldn't apply to data and for that reason there are directives to let assembler know if a label references a function or some data.

    Thursday, October 31, 2013 12:36 AM