Bugs item #954788, was opened at 2004-05-16 13:27
Message generated for change (Comment added) made by borutr
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=100599&aid=954788&group_id=599
Category: pic14 target
>Group: fixed
>Status: Closed
>Resolution: Fixed
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: Borut Razem (borutr)
Date: 2005-04-11 18:51
Message:
Logged In: YES
user_id=568035
Tested with MINGW sdcc version 2.4.8 #1004 on Windows XP and
it doesn't crash.
----------------------------------------------------------------------
Comment By: Hubert Sack (hsack)
Date: 2005-04-04 15:26
Message:
Logged In: YES
user_id=1160854
Try with current version. My be it's solved in 2.4.8 #987
(see changelog). I got the signal 11 too and detected a
memory allocation problem, which was solved by erik
----------------------------------------------------------------------
Comment By: Vangelis Rokas (vrokas)
Date: 2004-11-16 13:34
Message:
Logged In: YES
user_id=770505
This SIGSEGV has nothing to do with either declaring variables
in the main or completely rebuilding SDCC from scratch.
Tests I've done in the past showed that there is a memory
allocation leak, somewhere I didn't manage to identify until
now.
This problem shows up only in Windows/Cygwin builds, but
not in all of them, and not all the time (although when the
bug appears, it will continue to appear steadily in the specific
Windows build).
regards,
Vangelis
----------------------------------------------------------------------
Comment By: Slade Rich (slade_rich)
Date: 2004-11-15 00:57
Message:
Logged In: YES
user_id=849691
> 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.
It does not crash for me using Win2000 or using a cygwin
build of SDCC.
> The same PIC code gets compiled fine on Linux, with the
same
> SDCC version.
This would suggest to me that you should do a complete
rebuild of the code for the windows port.
Slade
----------------------------------------------------------------------
Comment By: Nobody/Anonymous (nobody)
Date: 2004-11-14 01:09
Message:
Logged In: NO
SDCC has a bug somewhere with declaring variables in main. I
saw the same problem and it works to make the declaration
of "xx" in main a "static".
----------------------------------------------------------------------
Comment By: Nobody/Anonymous (nobody)
Date: 2004-11-13 22: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-12 03: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-12 02: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 23: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
sourceforge@...
----------------------------------------------------------------------
Comment By: Paul Ashmore (ashmop)
Date: 2004-10-11 05: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
|