This is the mail archive of the
mailing list for the binutils project.
Re: Why “relocation truncated to fit”?
- From: "Maciej W. Rozycki" <macro at imgtec dot com>
- To: Florian Weimer <fw at deneb dot enyo dot de>
- Cc: <binutils at sourceware dot org>
- Date: Mon, 3 Oct 2016 13:36:08 +0100
- Subject: Re: Why “relocation truncated to fit”?
- Authentication-results: sourceware.org; auth=none
- References: <firstname.lastname@example.org>
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
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. :)