Re: [avr-libc-dev] rjmp across FLASHEND

[Joerg Wunsch]

As Bernhard Kuemel wrote:

> My avr-gcc (debian/squeeze, gcc version 4.3.5 (GCC)), as it seems,
> doesn't support rjmp across FLASHEND for ATmega168 (16K Flash):

Well, it's not the compiler but the linker that complains.  The
compiler doesn't know anything about that.

The decision appears to have been made deliberately:

(file bfd/elf32-avr.c in the binutils sources)

static bfd_reloc_status_type
avr_final_link_relocate (reloc_howto_type *    howto,
...
  switch (howto->type)
...
    case R_AVR_13_PCREL:
...
      /* Check for overflow.  */
      if (srel < -2048 || srel > 2047)
        {
          /* Relative distance is too large.  */

          /* Always apply WRAPAROUND for avr2, avr25, and avr4.  */
          switch (bfd_get_mach (input_bfd))
            {
            case bfd_mach_avr2:
            case bfd_mach_avr25:
            case bfd_mach_avr4:
              break;

            default:
              return bfd_reloc_overflow;
            }
        }

As you can see, the overflow is only accepted for devices with <= 8
KiB of flash ROM, in the assumption that the target address wraps
around there.  (Actually, that address wrap around is not even clearly
documented in the Atmel AVR instruction definitions; it can only be
implied from the sentence that on devices with up to 8 KiB, the RJMP
instruction can reach the entire memory.)

If you want to extend the possible wrap around TOP/BOTTOM to larger
devices, this check has to become more sophisticated in order to
distinguish real overflow situations from wrap around situations.  As
an additional problem, I'm not sure whether the linker has the
required information (ROMEND) available at all to make that kind of
decision.  Linking is done based on relatively coarse descriptions in
the linker script, rather than actual per-device values.

Why is this such a big problem to you?  On a device with 16 or more
KiB of flash, I cannot imagine the two bytes saved by an RJMP
instruction around TOP/BOTTOM really make such a big difference.

(The linker is part of the GNU binutils, so that's where to report
this, if you want to file a bug report.)
-- 
cheers, J"org               .-.-.   --... ...--   -.. .  DL8DTL

http://www.sax.de/~joerg/                        NIC: JW11-RIPE
Never trust an operating system you don't have sources for. ;-)