On Thu, 11 Sep 2003, Scott Dattalo wrote:
> On Wed, 10 Sep 2003, Steve Tell wrote:
> > Is it just me, or has the pic14 port broken badly in recent snapshots?
> > I confess that before compiling yesterday's shapshot, the last one I built
> > was from early april 2003, but with the sept 9 2003 snapshot I find:
> > - the regression tests in src/regression cause gpsim to core dump on every
> > single .cod file
> Have you upgraded your gputils? SDCC now generates relocatable code for
> gpasm and hence requires gpasm to support it. Theoretically, the output of
> the link and located code should be backwards compatible with old versions
> of gpsim.
Yes I've got the latest released gputils.
gplink -v yields "gplink-0.11.6 pre-alpha". similar for gpasm.
(relocatable sdcc output won't even compile with older 0.10.x gputils)
a typical gpsim gdb session and traceback is:
(gdb) set args --cli -c b.stc test.log
Starting program: /usr/local/bin/gpsim --cli -c b.stc test.log
gpsim - the GNUPIC simulator
type help for help
not using guigpsim>
Program received signal SIGSEGV, Segmentation fault.
0xfeb32d00 in strcmp () from /usr/lib/libc.so.1
#0 0xfeb32d00 in strcmp () from /usr/lib/libc.so.1
#1 0xff24aae0 in search_commands (s=@0xffbedb90) at command.cc:118
#2 0xff23ecc0 in handle_identifier (s=@0xffbedb90, op=0xff27359c) at scan.ll:275
#3 0xff23db44 in yylex () at scan.ll:195
#4 0xff23b5b0 in yyparse () at /usr/lib/bison.simple:432
#5 0xff24ad84 in parse_string (cmd_string=0xffbee4d8 "load c b.stc") at input.cc:197
#6 0x0001dd54 in main (argc=5, argv=0xffbee64c) at main.cc:246
I haven't looked further into gpsim because I can't seem to recompile it
since upgrading to gcc-3.2.2. Actually, I don't know for sure that the
sdcc regressions ever worked with gpsim on solaris; I used to run them at
home on linux-intel and haven't tried that yet this time around.
anyway, thanks for looking at this...