Re: Why “relocation truncated to fit”?

Maciej W. Rozycki macro@imgtec.com
Mon Oct 3 12:36:00 GMT 2016


On Sun, 2 Oct 2016, Florian Weimer wrote:

> I think the wording of these error messages is not particularly
> helpful.  “Truncated to fit” implies that the operation was somehow
> successful.  But as far as I can tell, this is always a hard error (and
> I can't see what would be possible otherwise).

 The message has been there like this since before history, so it may be 
hard to tell why it has been worded this way.  Maybe one of the old-timers 
remembers.  We could use "relocation overflow" I guess, following the name 
of the BFD error code it corresponds to.

> It would also be nice to include information about the bits in the
> relocation and the value which could not be encoded.  Perhaps this would
> error: R_MIPS_GOT_DISP cannot express relocation against `base_GHCziNum_zp_entry'
> note: Required value is 284940, but only 16 bits are available to encode it

 I'd rather go for a message like:

foo.o: In function `foo':
(.text+0x4): relocation overflow: R_MIPS_GOT_DISP against `base_GHCziNum_zp_entry': cannot encode a value of 0x4590c in a field of 16 bits

(no decimal numbers for addresses or parts of please and also note that an 
error is already implied unless "warning" is printed), so that there's a 
single line per error encountered -- there can be many in a single link as 
errors of this kind are not abortive and the linker proceeds to report all 
of them before it terminates unsuccessfully (so that you can fix them all 
at once rather than having to go through possibly lots of them 
iteratively).

 Implementing this is would be a tedious task though as relocation 
handling throughout all the target backends would have to be reviewed for 
necessary data to be supplied to the error handler.  Also special cases 
would have to be handled, e.g. in the MIPS target you referred to we have 
the R_MIPS_26 relocation whose limit is not the upper bits being zero- or 
sign-extended, but they have to match the bits of the memory location 
following the location of the relocation itself.  This would require a 
different message for the error report to make sense.  I expect other 
targets to have similar special cases.

 That said, you're welcome to propose a patch. :)

  Maciej



More information about the Binutils mailing list