This is the mail archive of the
mailing list for the binutils project.
Re: gold incremental file format on 64-bit
From: Cary Coutant <firstname.lastname@example.org>
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
> 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
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
For input archives members and global symbols each consume 4 bytes
So at the end of each of these incremental input sub-parts we may
need to emit a 4-byte alignment pad.