https://sourceware.org/bugzilla/show_bug.cgi?id=16788
--- Comment #13 from Andy Lutomirski <luto at mit dot edu> --- (In reply to Cary Coutant from comment #9) > > > Yes, in gold, the fill value is always 4 bytes in length. There's a FIXME > > > in > > > the code to support arbitrary lengths, but that seems unlikely to be the > > > problem here. > > > > Fixing it for one and two bytes would be trivial :) > > How does GNU ld determine the size? In gold, we treat the fill value as an > arbitrary expression, so by the time we get the actual value to use, we have > no idea how large the given value was. If it's based on the size of the > constant given (e.g., 0x9090 is two bytes and 0x00009090 is four bytes), > it's not trivial. If it's simply based on the magnitude (e.g., 0x9090 and > 0x00009090 are both two bytes), then yes, it probably is trivial -- but then > how would you express a fill pattern like 0x00009090 where you really want > 00 00 90 90 00 00 90 90 ...? Fair enough. I assume that GNU ld treats it as bytes instead of as an expression, but I've never checked. -- You are receiving this mail because: You are on the CC list for the bug. _______________________________________________ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
