This is the mail archive of the binutils@sourceware.org mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: ALIGN directive showing different behavior than documented


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



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]