From: SourceForge.net <no...@so...> - 2004-11-13 21:59:48
|
Bugs item #954788, was opened at 2004-05-16 04:27 Message generated for change (Comment added) made by nobody You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100599&aid=954788&group_id=599 Category: pic14 target Group: None Status: Open Resolution: None Priority: 5 Submitted By: Matthieu Speder (mspeder) Assigned to: Nobody/Anonymous (nobody) Summary: sdcc crashes with SIGSEGV signal Initial Comment: Sample code (main.c) : #include "16f628.h" unsigned char main(void) { unsigned char xx[1]; xx[0]=1; return xx[0]; } SDCC command : sdcc -mpic14 -p16f628 --verbose main.c SDCC Version : mcs51/gbz80/z80/avr/ds390/pic16/pic14/TININative/xa51 /ds400/hc08 2.4.1 (May 15 2004) (MINGW32) Running on Win XP Error Message: Processor: 16f628 sdcc: Calling preprocessor... sdcc: Generating code... Caught signal 11: SIGSEGV Other comments: Same code compiles without any problem for 8051. .asm file is partially generated, stop at _xx generation. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2004-11-13 13:59 Message: Logged In: NO The Windows port of SDCC crashes with SIGSEGV 11 on pretty much any PIC code I throw at it. It works fine for 8051 targets. I'll take a look at the problem by compiling the source code myself, if I get the time to. Meanwhile, there *is* a serious problem with the Windows build. The same PIC code gets compiled fine on Linux, with the same SDCC version. ---------------------------------------------------------------------- Comment By: Slade Rich (slade_rich) Date: 2004-10-11 18:43 Message: Logged In: YES user_id=849691 As it was only a couple of lines, I have cut and pasted the supplied code patch into pcode.c line 2797, and checked it in. With the PIC14 port there is no one seriously developing it, so this bug is a fix it yourself case. The PIC14 still needs a lot of work done to make it fully functional. > I have no idea how to checkin a bug fix in this system, or where it goes or what access rights I need. Where do I put comments like this ? To actually check in code you need to be a SDCC developer. I gained that privilege by pestering an SDCC administrator with lots of code patch for the PIC14. I will assist in applying code patches to the PIC14. > What verification of bug fixes happen before checking in ? The standard regression test for SDCC does not work for the PIC14 port as there is no support in UCSIM for PICs. With the PIC14 there was some code in sdcc\src\regression specifically written to test PIC14 with the use of GPSIM. Slade ---------------------------------------------------------------------- Comment By: Vangelis Rokas (vrokas) Date: 2004-10-11 17:14 Message: Logged In: YES user_id=770505 Attach a patch to the bug tracker and someone (it can be me will apply it to the sources). Remember to use: cvs diff -cp to get the diffs, otherwise there may be unsolved conflicts during merge. Vangelis ---------------------------------------------------------------------- Comment By: Paul Ashmore (ashmop) Date: 2004-10-11 14:29 Message: Logged In: YES user_id=618214 I'm looking for help. I found a problem in the PIC14 port while accessing arrays or structs multiple times. I've fixed the bug...I'll paste the code in later. The problem is that an Immediate data (legacy 8051) pcode structure is being copied and derferenced by the popCopyReg function (in pcode.c line 2797 in SDCC 2.4.4 checked out on 10/9/2004). The part of the struct being dereferenced is the regs part of the pCodeOpReg structure, which was never setup in the case of a PO_IMMEDIATE, but the literal part was. --------------------------- The old code is: pcor->r = pc->r; pcor->rIdx = pc->rIdx; pcor->r->wasUsed=1; The new code is: if (pcor->pcop.type == PO_IMMEDIATE){ PCOL(pcor)->lit = PCOL(pc)->lit; } else { pcor->r = pc->r; pcor->rIdx = pc->rIdx; pcor->r->wasUsed=1; } --------------------------- I've made this change to my private code (based on SDCC 2.4.4 checked out on 10/9/2004) So why am I asking for help ? I have no idea how to checkin a bug fix in this system, or where it goes or what access rights I need. Where do I put comments like this ? What verification of bug fixes happen before checking in ? Any docs I can read related to this. I guess I'm just new to sourceforge procedures. Paul sou...@as... ---------------------------------------------------------------------- Comment By: Paul Ashmore (ashmop) Date: 2004-10-10 20:50 Message: Logged In: YES user_id=618214 I ran into this same problem on the PIC14/16f628 too. My work around was to make the 'xx' array a static. Although doing this in main causes other problems - like the compile runs out of .init code space. So I move the variable declaration and the code that uses it to another function. I discovered other problems related to this: You get the same result if the variable is a 'struct'. There also seems to be a limit on the number of accesses you can do to a struct or array in the pic14 port. I've only just started using SDCC (in the last 2 weeks) so don't yet fully understand how to debug it - but I will get to the bottom of this nonsense. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100599&aid=954788&group_id=599 |