1. Forum
  2. Usenet
  3. COMP.SYS.APPLE2.PROGRAMME

  • Generic question about Apple2 / cc65 debugging

    From Colin Leroy-Mira@21:1/5 to All on Fri Aug 11 20:13:26 2023
    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/

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Oliver Schmidt@21:1/5 to All on Fri Aug 11 18:50:53 2023
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Colin Leroy-Mira@21:1/5 to All on Sat Aug 12 15:12:06 2023
    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/

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Oliver Schmidt@21:1/5 to All on Sat Aug 12 20:39:25 2023
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)