Kernel Debugging
3 posts, 2 voices
Andy S (2979)
504 posts
|
Is it possible to attach DDT or another debugger to the code for SWIs in the kernel? I specifically want to single step the code for OS_SpriteOp 60, SwitchOutputToSprite, implemented in vdugrafl. Is there an easy way to find the address of the SWI despatcher and jump table so I can use that to find the OS_SpriteOp code? |
Paolo Fabio Zaino (28)
1882 posts
|
@ Andy
Not directly no. DDT is specifically designed to debug user-space applications (both single and multi-tasking). You can however use some trick to “observe” the SWI behaviour in DDT, for example a simple one to describe on a post here is write some stub code in C to call your SWI and observe how it behaves. Another is, if you want to debug your SWI logic, write your module so it can also be compiled as a regular app with debug info and then debug in in DDT. You can however use other debuggers, for example, one that allows you to debug everything on RISC OS Kernel is JTAG, that requires a board with a JTAG port, the required JTAG-to-USB interface and a debugger on your PC that supports JTAG. There are also other options like using GDBServer and RemoteDB.
If I understand your question correctly yes, did you have a look at OS_ReadSysInfo?: https://www.riscosopen.org/wiki/documentation/show/OS_ReadSysInfo |
|
Andy S (2979)
504 posts
|
Not directly no. DDT is specifically designed to debug user-space applications (both single and multi-tasking). You can however use other debuggers, for example, one that allows you to debug everything on RISC OS Kernel is JTAG, that requires a board with a JTAG port, the required JTAG-to-USB interface and a debugger on your PC that supports JTAG. Ah, OK, thank you. I’ll carry on with my bodged RPCEmu debugger to do it then. :) If I understand your question correctly yes, did you have a look at OS_ReadSysInfo? I did look but not carefully enough it seems. Thanks. |
