Re: Why “relocation truncated to fit”?

Joel Sherrill joel.sherrill@oarcorp.com
Mon Oct 3 12:49:00 GMT 2016



On October 3, 2016 7:36:08 AM CDT, "Maciej W. Rozycki" <macro@imgtec.com> 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
>(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.

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
>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

--joel



More information about the Binutils mailing list