This is the mail archive of the
mailing list for the binutils project.
Re: Why “relocation truncated to fit”?
- From: Joel Sherrill <joel dot sherrill at oarcorp dot com>
- To: "Maciej W. Rozycki" <macro at imgtec dot com>,Florian Weimer <fw at deneb dot enyo dot de>
- Cc: "binutils at sourceware dot org" <binutils at sourceware dot org>
- Date: Mon, 3 Oct 2016 07:48:51 -0500
- Subject: Re: Why “relocation truncated to fit”?
- Authentication-results: sourceware.org; auth=none
- References: <email@example.com> <alpine.DEB.firstname.lastname@example.org>
On October 3, 2016 7:36:08 AM CDT, "Maciej W. Rozycki" <email@example.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
>> 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
> 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. :)