Re: Enable 0x10 alignment for aarch64 symbols as is done for x86_64

[K Jski <bielsk1 at vt dot edu>]

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
do
. = 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!

Sincerely,

Chris

On Thu, Apr 16, 2015 at 9:19 PM, Cary Coutant <ccoutant@gmail.com> 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);
>> *(.bss.__args_for_foo);
>>
>> 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).
>
> -cary