ALIGN directive showing different behavior than documented

[Andre Vieira]

I was point out to the fact that I sent the wrong output, so here it is:

$ arm-none-eabi-nm a.out | grep test
00001234 B test0
0000be01 B test1
0000bf00 B test2
0000bf34 B test3
0000bf00 B test4
0000bf34 B test6
0000c000 B test7
0000bf34 B test8
00000000 B test_section1

Sorry for that.

Kind Regards,
Andre Vieira

On 07/07/15 14:41, Andre Vieira wrote:
> Hello,
>
> Andreas Fritiofson reported at
> https://bugs.launchpad.net/gcc-arm-embedded/+bug/1471226 an issue
> regarding the ALIGN directive in linker scripts. As he points out the
> documentation says "ALIGN(align) is equivalent to ALIGN(., align)".
>
> See below an expanded version of his example.
>
> echo > test.c
>
> cat test.ld
> align = 0x100;
>
> SECTIONS
> {
>     .section_with_unaligned_end :
>       {
>       test_section1 = .;
>       . += 0x1234;
>       }
>     .test :
>       {
>       test0 = .;
>       . += 0xabcd;
>       test1 = .;
>       . = ALIGN(align);
>       test2 = .;
>       test3 = ALIGN(., align);
>       . = ALIGN(align);
>       test4 = .;
>       . += 0x22;
>       test6 = ALIGN(., align);
>       test7 = ALIGN(align);
>       test8 = ALIGN(., align);
>       }
>     /DISCARD/ : { *(*) }
> }
>
> $ arm-none-eabi-gcc test.c -T test.ld
>
> $ arm-none-eabi-nm a.out | grep test
> 00001234 B test0
> 0000be01 B test1
> 0000bf00 B test2
> 0000bf34 B test3
> 0000bf00 B test4
> 0000bf34 B test5
> 00000000 B test_section1
>
> As you can see I expanded his test with a couple more ALIGN calls to do
> a bit more exploring. They are obviously different so the documentation
> is misleading at best. Furthermore, as Andreas points out it seems that
> the binary operator calculates it's alignment relative to the start of
> the section. In this example, the start of section test this is 0x1234.
>
> After some digging I found that the unary operator uses the expression
> 'expld.dot' whereas the binary operator uses 'lhs.value'. The first
> gives an absolute value, whereas the second seems to hold a relative
> value to the section start.
>
> The fact that the unary operator uses new_rel_from_abs did raise some
> flags with me. Not entirely sure what the function is doing there.
>
> This leaves with some uncertainties to whether it's just a documentation
> issue or a faulty code. Please advise!
>
> Thank you in advance for the time spent on this, I know your plates are
> already quite full!
>
> Kind Regards,
> Andre Vieira
>