Hi,

You may have noticed I'm back in my retrocomputing rabbit hole, so a
question pops back in my mind that I didn't find a good solution to
last winter: how does one debug cc65-generated code while sucking at
assembly?

I have found workarounds: I use a special conio.h with definitions that
allow me to also build my programs for Linux x86_64, and then I can
more or less run and test my code with modern tools like gdb and
valgrind.
But that's far from perfect, given how the standard types differ in
size, and also, I do have some low-level code #ifdef'd __CC65__, which
I can't test in the same ways.

I test my programs runtime using Mame, and I know of its debugger. But
this is very very far from the comfort of gdb or valgrind, which have
mappings to the source files and can break and show variables anywhere
in the program.

I'm asking because I'm sometimes baffled by problems on which I can't
find anything to progress. (Like earlier, when I used a wrapper to
chdir() instead of chdir() in a function, and my program clearly had
huge, visible memory corruption issues before even reaching that code.

In these cases I can't help thinking "compiler bug!" but my experience
tells me that the problem probably comes from me, and the different
binary simply uncovers something hidden.

Would you folks have some pointers for me? (If it is of any use, I
develop on Linux)

Thanks!
--
Colin
https://www.colino.net/

Hi Colin,

> how does one debug cc65-generated code while sucking at
> assembly?

Certainly not the silver bullet you might be looking for, but what's there:

Build with options that generate additional files which allow you to relate
addresses you see in the monitor of an emulator to your source code.

1. Create a map file. It tells you where your functions are placed in
memory: --mapfile <file>

2. Create a listing file with source comments. It tells you which source
code line belongs to which offset: --listing <file> --add-source

So even when you don't understand assembly you can this way follow which
source code line is currently executed or set breakpoints on a source code
line.

Regards,
Oliver

Hi,

>2. Create a listing file with source comments. It tells you which
>source code line belongs to which offset: --listing <file> --add-source

I've tried using --listing --add-source before, but I can't understand
what I'm doing wrong. Maybe it's not supposed to be used directly with
the cl65 helper:

cl65 -t ... -o program --listing <file> [numerous .c files]

generates a listing for only the last c file of the list.
--
Colin
https://www.colino.net/

Hi Colin,

> I've tried using --listing --add-source before, but I can't understand
> what I'm doing wrong. Maybe it's not supposed to be used directly with
> the cl65 helper:
>
> cl65 -t ... -o program --listing <file> [numerous .c files]
>
> generates a listing for only the last c file of the list.

There's one listing file for each source file. So the approach above can
conceptually not work.

I don't know if this works:
cl65 -t ... -o program --listing a.lst a.c --listing b.lst b.c

Anyhow, I'd rather create each object file individually with this:
cl65 -c -t ... --listing x.lst --add-source x.c

Regards,
Oliver