* [Bug target/38549] [avr] eicall not properly set for > 128K program space
[not found] <bug-38549-4@http.gcc.gnu.org/bugzilla/>
@ 2010-11-02 20:26 ` johnstonj@inn-soft.com
2011-10-23 15:26 ` gjl at gcc dot gnu.org
` (2 subsequent siblings)
3 siblings, 0 replies; 7+ messages in thread
From: johnstonj@inn-soft.com @ 2010-11-02 20:26 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 7+ messages in thread* [Bug target/38549] [avr] eicall not properly set for > 128K program space
[not found] <bug-38549-4@http.gcc.gnu.org/bugzilla/>
2010-11-02 20:26 ` [Bug target/38549] [avr] eicall not properly set for > 128K program space johnstonj@inn-soft.com
@ 2011-10-23 15:26 ` gjl at gcc dot gnu.org
2014-02-16 13:14 ` jackie.rosen at hushmail dot com
2021-11-05 23:19 ` timturnerc at yahoo dot com
3 siblings, 0 replies; 7+ messages in thread
From: gjl at gcc dot gnu.org @ 2011-10-23 15:26 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 7+ messages in thread* [Bug target/38549] [avr] eicall not properly set for > 128K program space
[not found] <bug-38549-4@http.gcc.gnu.org/bugzilla/>
2010-11-02 20:26 ` [Bug target/38549] [avr] eicall not properly set for > 128K program space johnstonj@inn-soft.com
2011-10-23 15:26 ` gjl at gcc dot gnu.org
@ 2014-02-16 13:14 ` jackie.rosen at hushmail dot com
2021-11-05 23:19 ` timturnerc at yahoo dot com
3 siblings, 0 replies; 7+ messages in thread
From: jackie.rosen at hushmail dot com @ 2014-02-16 13:14 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 7+ messages in thread* [Bug target/38549] [avr] eicall not properly set for > 128K program space
[not found] <bug-38549-4@http.gcc.gnu.org/bugzilla/>
` (2 preceding siblings ...)
2014-02-16 13:14 ` jackie.rosen at hushmail dot com
@ 2021-11-05 23:19 ` timturnerc at yahoo dot com
3 siblings, 0 replies; 7+ messages in thread
From: timturnerc at yahoo dot com @ 2021-11-05 23:19 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 7+ messages in thread