On 03.05.12 00:17, Jim Brain wrote:
> I got further, but after copying back in all the code I had pulled
> out, it still complains about R_AVR_13_PCREL errors.
There are various ways to achieve an error making that reference. (Did
it also report "relocation truncated to fit:"? Last time I did it, the
cause was an rjmp where an ljmp was needed.)
[...]
> I understand it's a RJMP 13 bit address overrun issue during linking,
> but I am lost on how to address the issue.
Having neither complete error messages nor code, we are powerless to
offer specific advice. However, if it is a linking issue, then comparing
the address of the failing instruction and the address of the
destination, and examining the generated assembler code, should help
clarify whether you just need to change the code to better reach the
destination, or the compiler is letting you down, or ...
> Essentially the same code compiles fine for MEGA162, and the current
> codebase compiles fine if I leave off a few calls in main.c.
Perhaps the linker script differs a little when you compile for the
MEGA162. In any event, you are saying that the destination is then
placed within reach of the PC-relative instruction. And "if I leave off
a few calls" between the erroring code and the problem destination, it's
OK too. So it looks much like an rjmp/rcall needs replacing with an
ljmp/call. But why is it wrong now?
Posting the problem lines of source code, the error messages, and the
assembler generated for the offending sources line would render a
diagnosis feasible. Pasting the address of the destination, either from
the "DEFINED SYMBOLS" of a .lst file, or a .map would help inform
discussion.
Diagnosing bugs isn't a highly documented topic. It's not one where a
neat HOWTO can readily implant the experience and understanding which
only comes from reading and analysing problem code, theorising on
causes, and trying fixes. (Maybe it's the whack on the forehead, at the
Duh! moment, which helps most. In any event, there are few pat answers.)
Attempting to distil the problem code down to a small demonstration
case, perhaps with any convenient fill to place the destination at the
same distance, sometimes already reveals the nature of the cause. And if
it doesn't then possible mentors will appreciate not having to wade
through miles of irrelevant guff. So much so that they are much more
likely to look at it.
Erik
--
One man's constant is another man's variable.
- A.J. Perlis
_______________________________________________
AVR-GCC-list mailing list
AVR-GCC-list@nongnu.org
https://lists.nongnu.org/mailman/listinfo/avr-gcc-list
