Add --add-source cc65 flag in the C SDK and incorporate C comments in the code stepper

[ecdhe42]

Add the --add-source cc65 flag to the C SDK and display the commented code in the code stepper.

[nickgirardo]

Can cc65 output sourcemaps? This would be an absolute game-changer of a feature if it were possible

[ecdhe42]

After some further research, there seems to be a way to map the address in memory to an actual C function. Adding the -g fiag (add debug info) and ld65 --dbgfile myprogram.dbg generates a file which contains something like this:

file	id=2,name="hello.c",size=201,mtime=0x672BF5FC,mod=0
(...)
line    id=14,file=2,line=20,type=1,span=59
line    id=23,file=2,line=12,type=1,span=29
line    id=38,file=2,line=13,type=1,span=35
line    id=40,file=2,line=17,type=1,span=57
line    id=49,file=2,line=15,type=1,span=40
line    id=50,file=2,line=7,type=1,span=17
line    id=52,file=2,line=8,type=1,span=21
line    id=53,file=2,line=5,type=1,span=4
line    id=62,file=2,line=14,type=1,span=58+36
line    id=63,file=2,line=6,type=1,span=13
line    id=71,file=2,line=16,type=1,span=47
line    id=75,file=2,line=9,type=1,span=24
(...)
span	id=29,seg=0,start=37,size=7   // first line inside _main
span	id=35,seg=0,start=44,size=12
span	id=36,seg=0,start=56,size=3
span	id=40,seg=0,start=59,size=8
span	id=47,seg=0,start=67,size=13
span	id=60,seg=0,start=37,size=70   // span of the _main function
(...)
scope	id=2,name="_main",mod=0,type=scope,size=70,parent=0,sym=11,span=60

The span seems to contain the offset and size inside the segment.

So it should be feasible to pre-process this debug file to generate a file which matches the memory addresses of each line of C code (or at least the filename + line)

[nickgirardo]

Thanks for this, I'll take a look

[ecdhe42]

The algorithm I can think of is:

• Get the list of csym to get only the C symbols (variables and functions)
• Get the scopes for these symbols
• Look for files whose names end up in .c (and maybe only those in src, not in src/gt)
• Get the lines associated with those files
• Get the scopes associated with those lines. If more than one scope, get the earlier one
• Match the symbol scopes (whose address should be in map.out) with the line scopes

[clydeshaffer]

I tried taking an address and working backwards, and was able to get to the right C file and line number!

1. First I had to determine what segment the address was in. The spans are relative to the start of the segment, so we first need to find the segment's start address. In the automated version of this it'll need to figure it out from the ROM bank number as well. (Further baking the current flash cart design into the tooling but modularity I think can be saved for another issue)

2. Look for a segment that covers the address, remember that we're looking for the address minus the segment start, for the same seg id that we determined as well.

3. Looking for a line entry with the span number we can get the file and line number in that file. In a line entry the line column is just the line number and not an id into the lines, like it is when line= appears in other rows.

The first time I did this I got to an assembly file, and saw that the assembly file had a reference to the C file and line number.

But!! We can skip past checking the asm file for a .dbg line because the linker debug file is already aware of C files. In looking for a line entry that referenced the C file and the line that I found, I discovered that an address for code that comes from a C file will match to TWO span entries!

span	id=518,seg=0,start=714,size=3
span	id=519,seg=0,start=717,size=2 (this one)
span	id=520,seg=0,start=719,size=2
span	id=521,seg=0,start=721,size=3
span	id=522,seg=0,start=724,size=2
span	id=523,seg=0,start=726,size=2
span	id=524,seg=0,start=728,size=2
span	id=525,seg=0,start=714,size=16 (and this one)

It may be coincidental but the pattern appears to be that it prints several spans linked to lines of assembly, and then a span that links to a C line that the previous group of spans is derived from.

A given span entry is easy to determine whether it belongs to a C or Assembly file since the span points to a line entry which points to a file. There also seems to be an optional type property on line entries but I haven't found documentation to confirm my speculation. From a few spot checks it looks like type 1 indicates a C line, while type 2 indicates either it is an assembly macro or comes from a .mac file that contains macros.

[clydeshaffer]

Looking at the linker debug output some more, it seems like the next challenge is actually figuring out what bank an address belongs to. I've made a PR on cc65 to add bank info to dbginfo since it seems like it belongs there as much as the other info.

Locally I was able to use it to determine the C line for an address in the emulator

c7c7c6a

[clydeshaffer]

Now it's printing source code to the screen