1. Home
  2. Embedded Programming
  3. gpsim segfaults when loading a .cod with stack in linmem.

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

Reply to
Johann Klammer
Loading thread data ...

This goes away when using if(valueregisters[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

Reply to
Johann Klammer

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.