When you spend a full day tracking down a bug :-( Bug in SDCC 4.0?

Pagina 3/4
1 | 2 | | 4

Van pgimeno

Champion (289)

afbeelding van pgimeno

02-09-2020, 00:51

Hm, I'm using sdcc "3.5.0 #9253 (Mar 19 2016) (Linux)" and it does output "12345" for me. I've used https://github.com/sndpl/skeleton-sdcc-msx with this patch:

diff --git a/Makefile b/Makefile
index 2e10099..aa65f4d 100644
--- a/Makefile
+++ b/Makefile
@@ -3,7 +3,7 @@ ASM = sdasz80
 PLATFORM = -mz80
 EMULATOR = /Applications/openMSX.app/Contents/MacOS/openmsx -machine Philips_NMS_8255 -ext msxdos2 -diska emulation/msx-dos2/ -script emulation/boot.tcl -diskb bin/
 #EMULATOR = /Applications/openMSX.app/Contents/MacOS/openmsx -machine C-BIOS_MSX2 -carta
-HEXBIN = hex2bin
+HEXBIN = objcopy --input-target=ihex --output-target=binary
 
 STARTUPDIR = startups
 INCLUDEDIR = includes
@@ -11,7 +11,8 @@ LIBDIR = libs
 SRCDIR = src
 
 # See startup files for the correct ADDR_CODE and ADDR_DATA
-CRT0 = crt0msx_msxdos_advanced.s
+#CRT0 = crt0msx_msxdos_advanced.s
+CRT0 = crt0msx_msxdos.s
 ADDR_CODE = 0x0107
 ADDR_DATA = 0
 
@@ -47,8 +48,8 @@ $(SOURCES):
 
 build: main.ihx
 		@echo "Building $(OUTFILE)..."
-		@$(HEXBIN) main.ihx
-		@mv main.bin bin/${OUTFILE}
+		@mkdir -p bin
+		@$(HEXBIN) main.ihx bin/$(OUTFILE)
 		@echo "Done."
 
 clean:
diff --git a/src/main.c b/src/main.c
index 1578b13..a7b4232 100644
--- a/src/main.c
+++ b/src/main.c
@@ -1,7 +1,23 @@
-#include "conio.h"
-#include "dos.h"
+void fill(char *q)
+{
+  unsigned char n;
+  char p[6];
 
-void main(void) {
-    puts("Hello, world :-)\r\n");
-    exit(0);
+  // presence of this loop is important
+  for(n = 0; n < 6; n++)
+    p[n] = n + '0';
+
+  for(n = 0; n < 5; n++)
+    q[n] = p[1];  // p[1] is miscompiled here, incrementing p every iteration
+}
+
+#include <stdio.h>
+
+int main()
+{
+  char q[6];
+  fill(q);
+  q[5] = 0;
+  puts(q);
+  return 0;
 }

Then I copied msxdos.sys 1.03 and command.com 1.11 to bin/ and executed: openmsx -machine Philips_NMS_8250 -diska bin/, then ran the program with: main.

I wonder if it behaves differently with a latter version of SDCC.

Van Bengalack

Champion (393)

afbeelding van Bengalack

02-09-2020, 08:39

I used v4.0.0. Not sure how "safe" it is to swap versions using multiple concurrently installed versions. I've had problems with that earlier. But I might test later, after work. It seems like a nice thing to have -- 2-3 sets of different SDCC-versions in the system, just to rule out some suspicions here and there Big smile

Van Bengalack

Champion (393)

afbeelding van Bengalack

02-09-2020, 22:21

@pgimeno I tested on win64 using SDCC v3.6, and got the same as you: 12345.

Things have certainly changed in the later versions.

Van Bengalack

Champion (393)

afbeelding van Bengalack

02-09-2020, 22:31

@pgimeno - I have been testing for the SDCC-devs. And in the latest snapshot (4.0.3 #11846 (MINGW32)), "my" bug has not been fixed, but I can confirm that your example now runs fine Big smile "11111"

Van Bengalack

Champion (393)

afbeelding van Bengalack

02-09-2020, 23:33

Ha ha, latest update. The problem was actually fixed by the devs. Problem now is that printf is broken, so I couldn't see the real result. Using puts as pgimeno, revealed that it was fixed. So, I guess the fix will be in v4.1.0 -whenever that version comes out.

That said, I think the response time from the devs was really quick on this one.

Van pgimeno

Champion (289)

afbeelding van pgimeno

03-09-2020, 07:22

Cool, thanks for reporting back! And yes, it sounds serious enough as to get 100% of attention.

By the way, another problem I've found with SDCC is that it does not accept the syntax 3[p], only the syntax p[3]. GCC admits either without problems. Maybe since you're in contact with them you can let them know?

Van Bengalack

Champion (393)

afbeelding van Bengalack

03-09-2020, 15:28

pgimeno wrote:

the syntax 3[p], only the syntax p[3]

Really. I was not aware of that syntax. I have never seen it before (in any language). What is it called? And is it part of a certain version of the standard?

Van Pencioner

Scribe (1424)

afbeelding van Pencioner

03-09-2020, 16:14

This is a part of a C standard which says that x[y] equals to *(x+y) ... and since x+y == y+x you can change the order of operands Wink so for example a[b[c[0]]] can be written as 0[c][b][a] which is indeed funny Tongue

Van salutte

Master (135)

afbeelding van salutte

03-09-2020, 16:37

I just tried sdcc 3.8 and it supports the 3[p] syntax for me without a problem. Is there any known failure case?

Van PingPong

Prophet (3738)

afbeelding van PingPong

03-09-2020, 21:02

pgimeno wrote:

Cool, thanks for reporting back! And yes, it sounds serious enough as to get 100% of attention.

By the way, another problem I've found with SDCC is that it does not accept the syntax 3[p], only the syntax p[3]. GCC admits either without problems. Maybe since you're in contact with them you can let them know?

honestly, the syntax 3[p] even is in some hidden row of the c specs for some kind of "simmetricity" is one of the less seen syntax i've even seen and perhaps IMHO even a confusing one. it has it's root in the assumptions that those lines are equivalent in C:
char *c;
char data;

IF
data = *(c+2)
IS semantically equivalent to:

data = *(2+c)

then teoretically,

data= c[2]
should be semantically equivalent to
data 2[c].

but honestly it is something confusing. Not surprised that SDCC devs forgot to test this situation.
;-)

Pagina 3/4
1 | 2 | | 4