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: 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.


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