gold incremental file format on 64-bit
Fri Apr 20 22:55:00 GMT 2012
> One naggling issue with a native 64-bit sparc GOLD is that the
> incremental linking file format leads to many unaligned accesses which
> SIGBUS on sparc.
> Actually, much care has already been taken in the file format to put
> potentially 64-bit values into 8-byte sized and offsetted locations.
> But the individual sub-sections of the incremental linking file can
> end up not being 8-byte aligned.
> I intend to fix this by padding up each sub-section by enough to
> 8-byte align each one, when necessary, to fix this problem.
> What is the state of the incremental file format version? I need
> to increment it when I make this layout change, right? Or are we
> still at a point where we can just adjust things with impunity and
> without a version bump?
You should be able to align the supplemental info blocks without an
incompatible format change, since we find those via offsets stored in
the input file entries. All you'd need to do to preserve 8-byte
alignment is add 4 bytes of zeroes to each INCREMENTAL_INPUT_SCRIPT,
INCREMENTAL_INPUT_OBJECT, and INCREMENTAL_INPUT_ARCHIVE_MEMBER
supplemental info block.
Is there anything else that's unaligned?
> Also, it would have been nice for the gdb-index file format to not
> have the unaligned cases I ran into on 64-bit sparc the other week and
> fixed by using Swap_unaligned. How much flexibility exists to
> rearrange the gdb-index file layout?
The gdb index format is pretty experimental at the moment, so there is
flexibility, but I'd guess that it's probably going to get replaced
with something a bit more compact. The DWARF committee is about to
look at a similar index that Apple is using, so we'll probably end up
standardizing on something different from .gdb_index eventually. Thus,
it may not be worth bothering with it until then -- you'll have to
change binutils, gdb, and gold if you change the format. The
gdb-discuss mailing list would be the place to discuss changes to that
That said, the only unaligned pieces are the 64-bit values in the
address area, right? The only way to align that would be to extend the
third field from 32 bits to 64 bits. I think those pieces should
always be 4-byte aligned as is, though, so maybe it would be better to
have a version of Swap_unaligned that can handle 8-byte reads and
writes to 4-byte-aligned addresses. That should be considerably faster
than the pure unaligned version you're using now.
More information about the Binutils