From: Ullrich von Bassewitz (uz_at_musoftware.de)
Date: 2000-01-20 16:19:26
Hi! > I encountered a problem: VICE (Version 1.2) under Win32 complains > about an unexpected token at the end of each line of the token file. > It's CR/LF sequency which VICE does not like, since VICE always uses > Unix style line terminator (LF); so, currently, the label file is not > usable at all unless the file can be converted to unix style (which I > did for testing purposes with the help of Linux, and it worked well). I would say that this is a VICE problem, not a ld65 one. The label file and all other macro like files in VICE *are* text files, so VICE should treat them as such and expect the correct line termination for the operating system it runs on. If VICE expects a simple LF, it is not possible to generate a macro or label file using a text editor under Windows, something that would be useful. The VICE people may of course have a different view of the problem:-) I will send them a mail, they are usually very responsive. > Is there an option I did not find or is it even planned to generate > further debugging information, i.e., a mapping of code lines to > memory addresses, so that there would be the option of doing something > like a source level debugging? (Yes, I know, VICE lacks the functio- > nality 'til now, but I want to know of cc65 itself does something like > this)? Here is what I have currently in mind (this does mean that I have put some thoughts into it - it does not mean that the features will be in one of the next versions): * I will add a type for the generated symbols. This will allow a debugger to distinguish between memory labels, zero page locations and other constants. Currently all debug symbols are equal, and VICE uses the first symbol it finds to display memory reference - this often wrong. * Symbols will have an associated range, that says for which code addresses the symbol is valid. Currently local symbols are placed in the global address space and are visible from eyerywhere. This leads to a symbol table pollution. Both things are possible with the current compiler, but they are not supported by VICE. So, to make them usable, I will have to propose an extension to the VICE monitor. * Write a debugger that resides on the PC, has knowledge about all debugging information and connects to the real machine via a serial link using a small cc65 module that has to be linked to the application. This would mean that it is possible to develop the debugger independent of VICE, and that it is possible to support all platforms, not only the platforms that are emulated by VICE (the Plus/4 comes to mind, since it already has a 6551 UART). If have put some work into serial support lately to lay the ground for such a debugger, but it is a lot of work, so don't expect this to come soon. Currently it's just an idea. A source level debugger (as suggested by you) will not be possible with the current compiler, since the RD parser does not generate an abstract intermediate code. This means there is no chance to keep the debug/line information intact while the optimizer works on the generated assembler code. > I hope I will enjoy cc65. I hope that, too:-) Regards Uz -- Ullrich von Bassewitz uz_at_musoftware.de ---------------------------------------------------------------------- To unsubscribe from the list send mail to majordomo_at_musoftware.de with the string "unsubscribe cc65" in the body(!) of the mail.
This archive was generated by hypermail 2.1.3 : 2001-12-14 22:05:35 CET