sdcc-4.2.9 from sdcc-snapshot-amd64-unknown-linux2.5-20221030-13738.tar.bz2
on stm8s002f3
/*
* Hunting a bug
*/
#define MAIN
#include "nq.h"
void clock_init(void)
{
// system clock to run at 16MHz using the internal oscillator. RM0016 page 89
CLK->ICKR = 1; // High-speed internal RC on
CLK->ECKR = 0; // external clock off
CLK->SWR = 0xe1; // HSI as the clock source.
CLK->SWCR = 0x02; // Enable clock switch
CLK->CKDIVR = 0; // f_HSI=F_HSI_RC/1 f_CPU=f_MASTER
CLK->PCKENR1 = 0xff; // Enable all peripheral clocks.
CLK->PCKENR2 = 0xff; // Ditto.
}
uint8_t mod_100(int number)
{
return number % 100;
}
uint8_t mod_100_verbose(int number)
{
uint8_t i = number % 100;
dprint(" i=%d ",i);
return i;
}
int main(void)
{
int16_t m,n;
clock_init(); // need to be first
dprint_init(DPRINT_LEVEL); // set dprint_level and port as output
dprint("\n -- Bug hunting \"n=0; i=n%100;\" reset stm8s003f3 ");
while (1) {
dprint("n=%d ", n);
//m = mod_100(n);
m = mod_100_verbose(n);
dprint("\n m=%dreset will have occcured before this line is reached\n", m);
n++;
}
}
Resets the CPU, repeatedly
-- Bug hunting "n=0; i=n%100;" reset stm8s003f3 n=0 i=100
-- Bug hunting "n=0; i=n%100;" reset stm8s003f3 n=0 i=100
-- Bug hunting "n=0; i=n%100;" reset stm8s003f3 n=0 i=100
The assembler for the compiled mod_100() from main.lst
145 ; -----------------------------------------
146 ; function mod_100
147 ; -----------------------------------------
000021 148 _mod_100:
149 ; main.c: 23: return number % 100;
000021 4B 64 [ 1] 150 push #0x64
000023 4B 00 [ 1] 151 push #0x00
000025 CDr00r00 [ 4] 152 call __modsint
000028 9F [ 1] 153 ld a, xl
154 ; main.c: 24: }
000029 81 [ 4] 155 ret
156 ; main.c: 25: uint8_t mod_100_verbose(int number)
157 ; -----------------------------------------
158 ; function mod_100_verbose
159 ; -----------------------------------------
00002A 160 _mod_100_verbose:
161 ; main.c: 27: uint8_t i = number % 100;
00002A 4B 64 [ 1] 162 push #0x64
00002C 4B 00 [ 1] 163 push #0x00
00002E CDr00r00 [ 4] 164 call __modsint
000031 9F [ 1] 165 ld a, xl
166 ; main.c: 28: dprint(" i=%d ",i);
000032 88 [ 1] 167 push a
000033 C6u00u00 [ 1] 168 ld a, _dprint_level+0
000036 A1 00 [ 1] 169 cp a, #0x00
000038 84 [ 1] 170 pop a
000039 2C 01 [ 1] 171 jrsgt 00113$
00003B 81 [ 4] 172 ret
00003C 173 00113$:
00003C 5F [ 1] 174 clrw x
00003D 97 [ 1] 175 ld xl, a
00003E 88 [ 1] 176 push a
00003F 89 [ 2] 177 pushw x
000040 4Br00 [ 1] 178 push #<(___str_0+0)
000042 4Bs00 [ 1] 179 push #((___str_0+0) >> 8)
000044 CDr00r00 [ 4] 180 call __nqprintf
000047 5B 04 [ 2] 181 addw sp, #4
000049 84 [ 1] 182 pop a
183 ; main.c: 29: return i;
184 ; main.c: 30: }
00004A 81 [ 4] 185 ret
186 ; main.c: 31: int main(void)
187 ; -----------------------------------------
188 ; function main
189 ; -----------------------------------------
00004B 190 _main:
And finally I found this source code, although I don't know what is wrong, nor do I have fix yet.
sdcc/share/sdcc/lib/src/stm8/_modsint.s
.globl __modsint
.area CODE
__modsint:
ldw y, (#3, sp)
ld a, xh
jrpl __modsint_1
negw y
__modsint_1:
tnzw x
jrpl __modsint_2
negw x
__modsint_2:
divw x, y
tnz a
jrpl __modsint_3
negw y
__modsint_3:
ldw x, y
popw y
addw sp, #2
jp (y)
I tested the above code on sdcc-4.1.0, and this worked as expected
I should probably add that sdcc-4.2.0 also resets, I just tried with the newest build to make sure I didn't report an issue that was already fixed
PS: how can I edit the the original report ? I can and I have edited this reply, but it should be possible to fix typos and clarify a report as ones understandig of the issue improves
Last edit: StorePeter 2022-10-31
This could be a flawed adaptation to the new STM8 calling convention introduced with 4.2.0.
You can't. However, project members can do it. It would make sense to allow the original authors to edit the tickets they created, but I don't know whether that option exists.
Makes sense.
The CPU resets at the return from subroutine,
In my example it succesfull print "i=100" after the modulo % has been executed
well it should have been "i=0", another indication of a flawed stack.
For now I have downgraded to sdcc-4.1.0, if/when there is a fix, I will be happy to test it out.
Last edit: StorePeter 2022-10-31
It seems others have requested this feature from sourceforge back in 2014,
and the first comment was a call not to do it ;-(
https://sourceforge.net/p/forge/feature-requests/245/
Well I gave it a + so now we are 17 who thinks thats a feature worth having.
Maybe their system is not used much for bug-tracking,
I have done editing my bug-reports plenty of time in other systems, never seen it abused
SOLVED
The problem was that while I was testing sdcc-4.2, the new compiler was still picking up the old libraries from sdcc-4.1.0 which I had installed in /usr/local.
It seems like search under /usr/local/share/sdcc is hardcoded into sdcc.
Even when you have the defined the environment variable SDCC_HOME,
include files and libraries will be still be searched through under /usr/local/share/sdcc/{include,lib}
Unfortunately I had misspelled the path I had assigned to SDCC_HOME in my Makefile,
and there were no complains because the new compiler just picked up the old include files
and libraries
Last edit: StorePeter 2022-11-12
Closed in accordance with the author's findings.
Happy to hear that everything works as intended.