This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: gold incremental file format on 64-bit
From: Cary Coutant <ccoutant@google.com>
Date: Fri, 20 Apr 2012 16:16:12 -0700
>>> Is there anything else that's unaligned?
>>
>> Yes, some of the other sections can end up with an unaligned ending if
>> there is an odd number of entries because the individual objects are a
>> multiple of 4 bytes in size, but not a multiple of 8.
>
> As far as I can tell, besides .gnu_incremental_inputs, the only other
> section that has any address-sized items in it is
> .gnu_incremental_relocs. That would probably be a bug in
> Incremental_inputs::create_data_sections():
>
> this->relocs_section_ = new Output_data_space(4, "** incremental_relocs");
>
> That "4" should be "size/8", where we'd determine "size" in the switch
> statement above. That'll make sure the relocs section is properly
> aligned.
Yes, it's only the incremental inputs it seems.
For input objects and archive members, the global symbol entries
consume 20 bytes each and comdat groups consume 4 bytes each.
For input shared objects, global symbol entries consume 4 bytes
each.
For input archives members and global symbols each consume 4 bytes
each.
So at the end of each of these incremental input sub-parts we may
need to emit a 4-byte alignment pad.