#140 Break on execution label maps to incorrect address

[Windchine]

Using "break e label" from either stc file or command line sets the break at a different address to that which the label maps. Using "break e address" where address is in hex (0xnnnn) works correctly.

This occurs with builds built and running on Fedora 16 and for gpsim versions 0.23.0 to 0.26.1 as well as the F16 prebuilt package.

Attached are the stc and asm test files. Note that the nop commands are just there to provide somewhere for the break to land at - the same is observed with other op codes and other selected PIC types.

The stc break lands at address 0x0007. The command line entered breaks to xxx and yyy land at 0x0006 and 0x0008 respectively. These landing points are indicated on the source browser window and from command line:

**gpsim> break
0: test Execution at line_0007(0x7)
1: test Execution at line_0006(0x6)
2: test Execution at line_0008(0x8)

Breaks set by clicking in the source browser window set correctly. When the code is run the breaks happen at the lines shown in the source browser window which, for those entered by label, is the incorrect points.

At startup the simulator reports problems with some labels:

gpsim - the GNUPIC simulator
version: Release 0.26.1
type help for help
**gpsim> SimulationMode:51
**gpsim>
*** WARNING: adding label 'interrupt' to an invalid instruction
*** WARNING: adding label 'start' to an invalid instruction

Breaks cannot then be set for these labels:

**gpsim> break e start
break cannot be set on 'start'

[Windchine]

Test asm file

[Windchine]

Test simulator file

[Robert Pearce]

I cannot recreate your problem here (Gentoo, GPSim HEAD, gputils 0.13.6beta). The command in the STC and the ones you note in the description all do exactly what they should.

What version of gputils do you have?

[Windchine]

$ gpasm -v
gpasm-0.14.1 (Mar 6 2012)

I will attach the assembler output files:
test.cod
test.lst
test.hex

Thanks.

[Windchine]

Assembler output file

[Windchine]

Assembler output file

[Windchine]

Assembler output file

[Robert Pearce]

I can confirm that the "break e label" command behaves badly with your .COD file. I can also confirm that when I assemble your source code using gpasm-0.14.1 it produces the same results.

In fact, what looks to be happening is that the labels in the COD file written by gpasm-0.14.1 have half the value they should. You can confirm this using GPVC. I'm therefore going to reject this bug as it's clearly not a GPSim bug. Please report it against GPASM on the gputils project.

[Robert Pearce]

I've raised bug 3521796 in the gputils project, referring back to this bug for details.