This is the mail archive of the 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 <>
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

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.

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