#760 sdcc crashes with SIGSEGV signal

closed-fixed
nobody
5
2013-05-25
2004-05-16
Matthieu Speder
No

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.

Discussion

  • 16f628.h include file

     
    Attachments
  • Paul Ashmore
    Paul Ashmore
    2004-10-11

    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.

     
  • Paul Ashmore
    Paul Ashmore
    2004-10-11

    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@ashmoreisland.com

     
  • Vangelis Rokas
    Vangelis Rokas
    2004-10-12

    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

     
  • Slade Rich
    Slade Rich
    2004-10-12

    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

     
  • 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.

     
  • 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".

     
  • Slade Rich
    Slade Rich
    2004-11-14

    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

     
  • Vangelis Rokas
    Vangelis Rokas
    2004-11-16

    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

     
  • Hubert Sack
    Hubert Sack
    2005-04-04

    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

     
  • Borut Ražem
    Borut Ražem
    2005-04-11

    Logged In: YES
    user_id=568035

    Tested with MINGW sdcc version 2.4.8 #1004 on Windows XP and
    it doesn't crash.

     
  • Borut Ražem
    Borut Ražem
    2005-04-11

    • milestone: --> fixed
    • status: open --> closed-fixed