@MSGID: <20230811201326.30841582@laptop-sigfox>
2dc357fa
@REPLYADDR Colin Leroy-Mira <colin@colino.net>
@REPLYTO 2:5075/128 Colin Leroy-Mira
@CHRS: CP866 2
@RFC: 1 0
@RFC-Message-ID:
<20230811201326.30841582@laptop-sigfox>
@TZUTC: 0200
@TID: FIDOGATE-5.12-ge4e8b94
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/

--- Claws Mail 3.19.1git30 (GTK+ 2.24.33; x86_64-pc-linux-gnu)
 * Origin: A noiseless patient Spider (2:5075/128)
SEEN-BY: 5001/100 5005/49 5015/255 5019/40 5020/715
848 1042 4441 12000
SEEN-BY: 5030/49 1081 5075/128
@PATH: 5075/128 5020/1042 4441