gpsim segfaults when loading a .cod with stack in linmem.

the version is gpsim-0.31.0 # (Dec 30 2019)
the commandline was gdb --args gpsim -s ../pic/main.cod
Here's a debug session:

Program received signal SIGSEGV, Segmentation fault.
0xb7e28020 in PicCodProgramFileType::read_symbols (
    this=0xb7fa3b20 <g_CodFileType>, cpu=0x8074b40) at cod.cc:559
559               cpu->registers[value]->new_name(b);
p s
$7 = 0x80680fa "\006_stack\002"
p length
$8 = 6 '\006'
p s[length+1]
$9 = 2 '\002'
p get_be_int(&s[length + 3])
$10 = 8816
(gdb) p s[length+3]
$11 = 0 '\000'
(gdb) p s[length+4]
$12 = 0 '\000'
(gdb) p s[length+5]
$13 = 34 '"'
(gdb) p s[length+6]
$14 = 112 'p'
(gdb) p s[length+2]
$15 = 0 '\000'

the 8816(=0x2270) is correct. mapfile has:
                   _stack   0x002270       data     extern
               _stack_end   0x00235b       data     extern

it's from the linker file which has:
[...]
STACK SIZE=0x00EC RAM=linear0

processor is 16f1705. adress is within limits..

This goes away when using
          if(value<0x2000) {
            get_string(b, s, sizeof b);
            cpu->registers[value]->new_name(b);
          }
in the proper place.
After fixing this, the executable loads but I get another 
fault when running at:

CLC_BASE::outputCLC (this=0x8078960, out=true) at clc.cc:976
976             CLCxsrc->setState(out ? '1' : '0');


It has to do with the LCxEN which does not exist on all variants.
is triggered by:
        MOVLW (1<<LC1EN)|(B'010'<<0);4-AND
	MOVWF CLC1CON

goes away when using:
        MOVLW (1<<LC1EN)|(B'010'<<0)|(1<<6);4-AND
	MOVWF CLC1CON

Then I'm getting one at:
0xb7e24bb9 in CLC_BASE::oeCLCx (this=0x8078960, on=true) at clc.cc:794
794                 name[3] = '1' + index;

It's caused by the PPS registers being set after that MOVWF
If I do that earlier, this goes away aswell.


Now it runs, but I get a watchdog expire.
I am waiting for the CCP1 interrupt flag to get set, but this never happens.

I am using CCP1,2 and PWM3. It's possible my code is at fault here if
the PWM3 and a ccp share resources. I haven't quite figured that out.
there's a bit of activity on those pins..
or it might be sthg else..


0x000000000003E6FE p16f1705 0x0701 0x33FE bra   $-0x2   ;(0x00e00)
92:     BRA $-1
  Wrote: 0x005A to ccpr1h(0x0292) was 0x005A
  Wrote: 0x0090 to pwm3con(0x0619) was 0x00B0
  Read: 0x0013 from pir1(0x0011)
  Wrote: 0x0013 to pir1(0x0011) was 0x0013
[...]
0x000000000003E718 p16f1705 0x0700 0x1D11 btfss pir1,2
91:     BTFSS PIR1,CCP1IF
  Wrote: 0x00B0 to pwm3con(0x0619) was 0x0090
  Read: 0x0013 from pir1(0x0011)
0x000000000003E733 p16f1705 0x0700 0x1D11 btfss pir1,2
91:     BTFSS PIR1,CCP1IF
  Wrote: 0x005A to ccpr1h(0x0292) was 0x005A
  Wrote: 0x0090 to pwm3con(0x0619) was 0x00B0
  Read: 0x0013 from pir1(0x0011)
  Wrote: 0x0013 to pir1(0x0011) was 0x0013
  Read: 0x0013 from pir1(0x0011)



Giving up for now...