Re: Why “relocation truncated to fit”?

Joel Sherrill
Mon Oct 3 12:49:00 GMT 2016

On October 3, 2016 7:36:08 AM CDT, "Maciej W. Rozycki" <> wrote:
>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
>> 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
>remembers.  We could use "relocation overflow" I guess, following the
>of the BFD error code it corresponds to.

When we see this linking RTEMS applications, it is just one if a handful of odd messages that equate to "the program doesn't fit in memory". Generally some section has too much in it.

Details usually don't matter if it is a test. We mark it as a fail to link and continue. If it is a real application, then someone has work to do to find and trim some fat in their code. :)

Is there any other response from a user? What could be reported that would help? It may not be this item that is the problem but the previously added huge element that unintentionally consumed the section.

>> It would also be nice to include information about the bits in the
>> relocation and the value which could not be encoded.  Perhaps this
>> error: R_MIPS_GOT_DISP cannot express relocation against
>> 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
>error is already implied unless "warning" is printed), so that there's
>single line per error encountered -- there can be many in a single link
>errors of this kind are not abortive and the linker proceeds to report
>of them before it terminates unsuccessfully (so that you can fix them
>at once rather than having to go through possibly lots of them 
> Implementing this is would be a tedious task though as relocation 
>handling throughout all the target backends would have to be reviewed
>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
>the R_MIPS_26 relocation whose limit is not the upper bits being zero-
>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