#1669 PIC16: pointer bug: loosing __data / __code upper address

[strobla]

Resubmitted as bug artifact as requested from Maarten:

Since SDCC revision 5531 I am not able to compile a stable version of
my pic webserver (pic18f2620 based) project any more. Attached you can find a tar file
containing all assembler output and listings of a minimal subpart of
my project to help you find the possible bug.
In subdirectory r5530 you can find the listings of the last usable
compile run.
In subdirectory r5882 you can find the listings of the broken hex file
Also included is a diff file showing the differences of main.asm

My assembler-knowledge of pic16 is very low, but I think there is
something wrong with pointers. "debug.log" shows some output:
r5882-compiled project is unstable and reboots after some seconds of
run time. r5530-compiled project is running properly as expected.

See also answer from Raphael below

Regards,
Strobl Anton

------------------------------------------------------------------------------
Re: [sdcc-devel] Pointer BUG? Persistent since sdcc r5531 and up for pic16 processors (virus scanned)
From: Raphael Neider <rneider@we...> - 2010-07-19 16:50

Hi Anton,

> Also included is a diff file showing the differences of main.asm

Very helpful indeed.

> [...] I think there is something wrong with pointers.

The problem is probably the introduction of UPPER(_ResolveMac_search_1_1)
(which returns the third, most significant byte of the address of symbol,
which in turn is almost inevitably 0x00) instead of the hard-coded 0x80
(which signifies __data space in PIC16 generic pointers; 0x00 would point
to __code space ...). I guess the behaviour changed after some
modification to the CAST operator down below in the AST, but could not
pinpoint the source (or fix it).

I am busy dealing with my PhD thesis, so I will probably not be able to
dig into this any time soon :-(

If anyone wants to help -- you are very welcome.

Best regards,
Raphael

[strobla]

diff between r5530 and r5882

[strobla]

minimized project to reproduce bug

[strobla]

Changed priority: without a fix sdcc PIC16 port is only usable up to and including sdcc revision 5530

[Raphael Neider]

As a (permanent?) workaround, you can replace

<code edited="yes">
void ResolveMac(unsigned char *ip) {
unsigned char search[SIZE_IP];
memcpy(&search, ip, SIZE_IP);
}
</code>

with either "memcpy(search, ip, SIZE_IP);" or "memcpy(&search[0], ip, SIZE_IP);".
Obviously, this would have to be done every time a pointer to (the first element of) a static array is requested, as the PIC16 code generator seemingly interprets "&search" as the address of the pointer "search" -- one excess level of indirection.

I believe the original code is valid and should work, so there is a bug here. Still working on it.

[Maarten Brock]

Please try again with #5904. This might be related to bug 1962613 that was fixed today.

[strobla]

Dear Maarten,

tested with r5905 but problem is persistent:

* upper address should be 0x80 (data space) which is in r5530 hardcoded 0x80 and correct.
* r5531 and up to r5905 function "UPPER" resolves to 0x00 which is code space and wrong

BTW: Raphael's workaround tip to use &search[0] instead of &search does help but think is only a temporary solution

Below see some diff lines of generated / linked assembler code (r5530 => r5905)

Regards, Strobl Anton

; .line 112; main.c memcpy(&search, ip, SIZE_IP);
-002900 6ae5 clrf 0xe5, 0 CLRF POSTDEC1
-002902 0e04 movlw 0x4 MOVLW 0x04
+0028f4 6ae5 clrf 0xe5, 0 CLRF POSTDEC1
+0028f6 0e04 movlw 0x4 MOVLW 0x04
+0028f8 6ee5 movwf 0xe5, 0 MOVWF POSTDEC1
+0028fa 5002 movf 0x2, 0, 0 MOVF r0x02, W
+0028fc 6ee5 movwf 0xe5, 0 MOVWF POSTDEC1
+0028fe 5001 movf 0x1, 0, 0 MOVF r0x01, W
+002900 6ee5 movwf 0xe5, 0 MOVWF POSTDEC1
+002902 5000 movf 0, 0, 0 MOVF r0x00, W
002904 6ee5 movwf 0xe5, 0 MOVWF POSTDEC1
-002906 5002 movf 0x2, 0, 0 MOVF r0x02, W
+002906 0e00 movlw 0 MOVLW UPPER(_ResolveMac_search_1_1)
002908 6ee5 movwf 0xe5, 0 MOVWF POSTDEC1
-00290a 5001 movf 0x1, 0, 0 MOVF r0x01, W
+00290a 0e00 movlw 0 MOVLW HIGH(_ResolveMac_search_1_1)
00290c 6ee5 movwf 0xe5, 0 MOVWF POSTDEC1
-00290e 5000 movf 0, 0, 0 MOVF r0x00, W
+00290e 0ee3 movlw 0xe3 MOVLW LOW(_ResolveMac_search_1_1)
002910 6ee5 movwf 0xe5, 0 MOVWF POSTDEC1
-002912 0e80 movlw 0x80 MOVLW 0x80
-002914 6ee5 movwf 0xe5, 0 MOVWF POSTDEC1
-002916 0e00 movlw 0 MOVLW HIGH(_ResolveMac_search_1_1)
-002918 6ee5 movwf 0xe5, 0 MOVWF POSTDEC1
-00291a 0ee3 movlw 0xe3 MOVLW LOW(_ResolveMac_search_1_1)
-00291c 6ee5 movwf 0xe5, 0 MOVWF POSTDEC1
-00291e ecad call 0x315a, 0 CALL _memcpy
-002920 f018
-002922 0e08 movlw 0x8 MOVLW 0x08
-002924 26e1 addwf 0xe1, 0x1, 0 ADDWF FSR1L, F
+002912 ec9b call 0x3136, 0 CALL _memcpy
+002914 f018
+002916 0e08 movlw 0x8 MOVLW 0x08
+002918 26e1 addwf 0xe1, 0x1, 0 ADDWF FSR1L, F

sdcc uses gpasm version: 0.13.7 r569 (gpasm r572 and up is broken for pic16 target)

[Philipp Klaus Krause]

Reduced priority, since this issue affects only pics.

Philipp