[Bug target/38549] [avr] eicall not properly set for > 128K program space

[Bug target/38549] [avr] eicall not properly set for > 128K program space

[johnstonj@inn-soft.com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38549

johnstonj@inn-soft.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |johnstonj@inn-soft.com

--- Comment #5 from johnstonj@inn-soft.com 2010-11-02 20:25:05 UTC ---
I can confirm this is indeed a problem.  I am developing a bootloader for
ATxmega128A1 (128 KB app flash + 8 KB bootloader = 136 KB flash total).  My
code:

#define PROG_START         0x0000
  (*((void(*)(void))PROG_START))();            //jump

This emits the following:

# Notice on reset, EIND register is written to a 1 as shown here.
# I searched the entire emitted disassembly and found no other
# reference to the I/O address for EIND.
000202e0 <__ctors_end>:
...
   202ec:    01 e0           ldi    r16, 0x01    ; 1
   202ee:    0c bf           out    0x3c, r16    ; 60


# Notice that Z is set to 0, as expected.  However, EIND is not
# set to 0 and so the processor attempts to do the jump to
# the location specified by EIND == 1 and Z == 0, which isn't a valid
# place to jump to.
  (*((void(*)(void))PROG_START))();            //jump
   20590:    e0 e0           ldi    r30, 0x00    ; 0
   20592:    f0 e0           ldi    r31, 0x00    ; 0
   20594:    19 95           eicall

Presumably this will come up much more frequently now that the ATxmega
processors are available:  all of these have so much flash that I would imagine
this will be a frequent problem.

I assume the problem happens with EIJMP which also uses EIND.

I notice that eicall / eijmp are used in libgcc.s.  I wouldn't be surprised if
there are bugs there, too - but did not investigate further.

My fix is simple; just set EIND = 0 before my jump.  However it leaves little
faith in my compiler for the application itself, since I don't know if it will
work reliably on AVR with large flash space for all jumps and calls, etc.

[Bug target/38549] [avr] eicall not properly set for > 128K program space

[gjl at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38549

Georg-Johann Lay <gjl at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |gjl at gcc dot gnu.org
         Resolution|                            |INVALID

--- Comment #6 from Georg-Johann Lay <gjl at gcc dot gnu.org> 2011-10-23 15:24:15 UTC ---
Closed as INVALID.

In the remainder you find an ouline of how to cope with indirect jumps on
devices with more than >128 KiB of code.

Actually, the flaw is that the following explanation is not yet part of the
documentation, see PR50820.

* The compiler never sets EIND.

* The startup code from libgcc never sets EIND.
  Notice that startup code is a blend of code from libgcc and avr-libc.
  For the impact of avr-libc on EIND, see avr-libc documentation.

* The compiler uses EIND in EICALL/EIJMP instructions or might read
  EIND directly.

* The compiler assumes that EIND is not changed during startup code or
  run of the application. In particular, EIND is not saved/restored in
  function or interrupt service routine prologue/epilogue.

* It is legitimate for user-specific startup code to setup EIND
  early, for example by means of initialization code located in
  section .init3 prior to general startup code that initializes
  RAM and calls constructors.

* For indirect calls to functions and computed goto, the linker will
  generate stubs. Stubs are jump pads sometimes also called trampolines.
  Thus, the indirect call/jump will jump to such a stub.
  The stub contains a direct jump to the desired address.

* Jump pads will be generated automatically by the linker if
  - the address of label is taken like so
       LDI r24, lo8(gs(func))
       LDI r25, hi8(gs(func))
  - and if the final location of that label is in a code segment
   *outside* the segment where the stubs are located.

  The compiler will emit gs() relocations (short for generate
  stubs) if the address of a label is taken.

* Addresses of labals are taken in the following situations:
  - Taking address of of a function or code label
  - Computed goto
  - If prologue-save function is used, see -mcall-prologues
    command line option
  - Switch/case dispatch tables. If you do not want such dispatch
    tables you can specify the -fno-jump-tables command line option.
  - C and C++ constructors called during startup
  - C and C++ destructors called during shutdown
  - If the tools hit a gs() directive explained above

* The default linker script is arranged for code with EIND = 0.
  If code is supposed to work for a setup with EIND != 0, a custom
  linker script has to be used in order to place the sections whose
  name start with .trampolines into the segment where EIND points to.

* Jumping to a non-symbolic addresse like so:

    int main (void)
    {
        // Call function at word address 0x2
        return ((int(*)(void)) 0x2)();
    }

  is /not/ supported.  Instead, a stub has to be set up like so:

    int main (void)
    {
        extern int func_4 (void);

        // Call function at byte address 0x4
        return func_4();
    }

   and the application be linked with -Wl,-defsym=func_4=0x4

[Bug target/38549] [avr] eicall not properly set for > 128K program space

[jackie.rosen at hushmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38549

Jackie Rosen <jackie.rosen at hushmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jackie.rosen at hushmail dot com

--- Comment #7 from Jackie Rosen <jackie.rosen at hushmail dot com> ---
*** Bug 260998 has been marked as a duplicate of this bug. ***
Seen from the domain http://volichat.com
Page where seen: http://volichat.com/adult-chat-rooms
Marked for reference. Resolved as fixed @bugzilla.

[Bug target/38549] [avr] eicall not properly set for > 128K program space

[timturnerc at yahoo dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38549

Tim Turner <timturnerc at yahoo dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |timturnerc at yahoo dot com

--- Comment #8 from Tim Turner <timturnerc at yahoo dot com> ---
"The strncat() function shall append not more than n bytes (a null byte and
bytes that follow it are not appended) from the array pointed to by s2 to the
end of the string pointed to by s1." http://www-look-4.com/category/technology/

The wording imply that the third "n" argument is an additional boundary limit,
not the destination buffer capacity (ie. the destination buffer is not
implicitly SIZE_MAX), https://komiya-dental.com/health/healthy-foods/ and both
source and destination do not overlap (overlapping depends on the source and
destination layout, not on the "n" value)
http://www.iu-bloomington.com/computers/invisible-with-vpn/

However, it seems that the optimized strncat version of the GLIBC behaves
incorrectly, when using this value. https://waytowhatsnext.com/sports/navona/
"The strncat() function shall append not more than n bytes (a null byte and
bytes that follow it are not appended) from the array pointed to by s2 to the
end of the string pointed to by s1."
https://www.webb-dev.co.uk/sports/sports-and-health/
The wording imply that the third "n" argument is an additional boundary limit,
not the destination buffer capacity (ie. the destination buffer is not
implicitly SIZE_MAX), and both source and destination
http://www.wearelondonmade.com/category/tech/ do not overlap (overlapping
depends on the source and destination layout, not on the "n" value)

However, it seems that the optimized strncat version of the GLIBC behaves
incorrectly, when using this value.
http://www.jopspeech.com/category/technology/
"The strncat() function shall append not more than n bytes (a null byte and
bytes that follow it are not appended) from the array pointed to by s2 to the
end of the string pointed to by s1."
http://joerg.li/category/technology/
The wording imply that the third "n" argument is an additional boundary limit,
not the destination buffer capacity (ie. the destination buffer is not
implicitly SIZE_MAX), and both source and destination do not
http://connstr.net/category/technology/ overlap (overlapping depends on the
source and destination layout, not on the "n" value)

However, it seems that the optimized strncat version of the GLIBC behaves
incorrectly, when using this value.
http://embermanchester.uk/category/technology/
"The strncat() function shall append not more than n bytes (a null byte and
bytes that follow it are not appended) from the array pointed to by s2 to the
end of the string pointed to by s1."
 http://www.slipstone.co.uk/category/technology/
The wording imply that the third "n" argument is an additional boundary limit,
not the destination buffer capacity (ie. the destination buffer is not
implicitly SIZE_MAX), and both source and destination do not overlap
http://www.logoarts.co.uk/category/technology/ (overlapping depends on the
source and destination layout, not on the "n" value)

However, it seems that the optimized strncat version of the GLIBC behaves
incorrectly, when using this value.
http://www.acpirateradio.co.uk/category/technology/
"The strncat() function shall append not more than n bytes (a null byte and
bytes that follow it are not appended) from the array pointed to by s2 to the
end of the string pointed to by s1."
http://www.compilatori.com/category/technology/

The wording imply that the third "n" argument is an additional boundary limit,
not the destination buffer capacity (ie. the destination buffer is not
implicitly SIZE_MAX), and both source and destination do not overlap
(overlapping depends on the source and destination layout, not on the "n"
value) 

However, it seems that the optimized strncat version of the GLIBC behaves
incorrectly, when using this value.

[Bug target/38549] [avr] eicall not properly set for > 128K program space

[eric dot weddington at atmel dot com]

-- 

eric dot weddington at atmel dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|0                           |1
   Last reconfirmed|0000-00-00 00:00:00         |2009-03-23 16:43:12
               date|                            |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38549

[Bug target/38549] [avr] eicall not properly set for > 128K program space

[eric dot weddington at atmel dot com]

------- Comment #4 from eric dot weddington at atmel dot com  2009-03-23 16:42 -------
*** Bug 38057 has been marked as a duplicate of this bug. ***


-- 

eric dot weddington at atmel dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |optech_tr at yahoo dot com


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38549

[Bug target/38549] [avr] eicall not properly set for > 128K program space

[thiago dot correa at gmail dot com]

------- Comment #3 from thiago dot correa at gmail dot com  2009-03-23 16:33 -------
Bug #38057 reports the same issue. Perhaps this should be changed to CONFIRMED
and one of the bug reports set as duplicate.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38549