This is the mail archive of the
mailing list for the binutils project.
Re: Enable 0x10 alignment for aarch64 symbols as is done for x86_64
- From: K Jski <bielsk1 at vt dot edu>
- To: Cary Coutant <ccoutant at gmail dot com>
- Cc: Binutils <binutils at sourceware dot org>, Antonio Barbalace <antoniob at vt dot edu>
- Date: Fri, 17 Apr 2015 12:21:40 -0400
- Subject: Re: Enable 0x10 alignment for aarch64 symbols as is done for x86_64
- Authentication-results: sourceware.org; auth=none
- References: <CAH=yU0YozLe6hgeQK_1ni8CWT9Na6U2WV3GYgFE-moq46DEqfQ at mail dot gmail dot com> <CAJimCsHhQfsTh4GnzAajB_P5foDxew9utz606T=0z8sLQ1eGew at mail dot gmail dot com> <CAH=yU0YLyuR72bQwQZ6Zw4OvkMj3wZOc_bmBeV_6xAju=r+NCQ at mail dot gmail dot com> <CAH=yU0bDBTzPUQssERB=THs-6HzH1Q2SmAtzgzH2bJ+i9ofzYA at mail dot gmail dot com> <CAJimCsGDiYipS4fzAJaWBg77QHc1_SbXQGH0Q_Wu6-FARB7bfA at mail dot gmail dot com> <CAH=yU0YcrNWUN=K9xD6Dg8uAZ=hA5H6WE+gOZ-e82iSAzT5NyA at mail dot gmail dot com> <CAH=yU0ZtcEjmp4EjqBdSk+J36m1G79x2rOKbDG1waTVt8FfN6g at mail dot gmail dot com> <CAJimCsGFFZkniJCwJe0ifA9e2VX8Jy7ThFpLwoDNiWAdfW-djw at mail dot gmail dot com> <CAH=yU0Y5OjLQCPYVC_A=t_RtHukD-32nM7ef96X3R6rxwxBvng at mail dot gmail dot com> <CAJimCsHLHU77X8otDQ4-WvyN8zmDLcdRhmhuBvSCZSSmKi6h8w at mail dot gmail dot com>
Dear Mr. Coutant,
Essentially, code fill is the difference between when compiling for
x86 and aarch64. I need the process to be the same so that the
binaries are as similar as possible for my main goal of symbol
alignment. For now I am creating a linker script that performs . =
ALIGN(0x10) for the symbols I am interested in making sure that they
are aligned on the aarch64 side of linking.
Update: You were correct about trying -fno-common! I checked nm for
the object and __args_for_foo was indeed a C (common) symbol. Once I
added -fno-common to the compiler, gold did follow my linker script to
. = ALIGN(0x10) on the aarch64 side just like is already done by x86
by the compiler.
You are also correct about aarch64 performing code relaxation
(convert_input_sections_to_relaxed_sections in output.cc) as opposed
to x86 not calling this function
Though, if it is possible though it would be much better if I could
force this into the compiler itself (for the aarch64 linking to do the
0x10 code fill) instead of through a linker script so I'm still
looking into the add_input_section function and do_write, though from
my output it seems do write seems to happen near the end. I'm still
fairly new to digging this deep into gold to accomplish my goals.
Thanks for the help so far!
On Thu, Apr 16, 2015 at 9:19 PM, Cary Coutant <firstname.lastname@example.org> wrote:
>> To put a long story short, I am trying to create an alignment tool for
>> x86_64/ aarch64 binaries to align sections/symbols to be at the same
>> addresses within both binaries (to enable cross architecture migration
>> of the program, this way both architectures have the same symbol
>> alignment when moving the program between ISAs and will access the
>> correct address when on either system). I am also providing gold with
>> a linker script to align .text, .rodata, .data, and .bss symbols.
>> e.g. function foo, will be at 0x4100000 for both the x86 binary and
>> aarch64 binary, as well as __args_for_foo will be at 0x4f0030 within
>> both the x86 and aarch64 binary, etc.
>> For the time being I've copied over the x86_64 implementation of
>> Target_aarch64::do_code_fill() into aarch64.cc so that it is still
>> possible to fille the section with something.
> What does code fill have to do with all of this?
>> The actual problem I am running into is that I am finding I have no
>> control over alignment of bss symbols even though I have wrote it in
>> the linker script.
>> e.g. __args_for_foo is at 0x4f00238 on aarch64 (not aligned) and is at
>> 0x4f00240 on x86_64 (aligned to 0x10)
>> even though I have :
>> . = ALIGN(0x10);
>> within the bss section of the aarch64 linker script.
> What does the output of 'nm' show for the object file that contains
> the definition of __args_for_foo? I'm guessing it's not actually a
> defined symbol in its own section, but a common symbol instead. There
> is no way to control the allocation of common symbols in a linker
> script. You can try using the GCC -fno-common option to force the
> compiler to allocate uninitialized definitions in the .bss section (or
> in their own .bss.* section if you are using -fdata-sections).