Debug WG 12/21/16 Notes
Cyril Jean
Please find below my notes of the December 21st, 2016 Debug Working Group video call. Let me know if I have mis-quoted anybody.
Introduction:
Tim - Changed the goal to agree run control debug spec by February 2017. This is a more realistic goal.
New people:
Leway - From China. Works for Credo Semiconductors. Uses rocket chip.
Vyacheslov: Works for Syntacore in Russia. Did presentation at the workshop.
Discussion:
Tim - non-invasive debugging discussed last week. We should try to come up with a definition. Megan did come up with a definition on the mailing list.
Larry - This should be called non-intrusive debugging.
Vyacheslov - Non-intrusive debugging sounds like tracing or probing. The need of tracing is obvious from middle and up implementations.
Tim - How much can we affect the processor? This can become difficult for complex systems.
Richard - Non-intrusive RTOS debug nice article can be found on Design and Reuse: https://www.design-reuse.com/articles/23942/real-time-non-intrusive-debugging-framework.html
Tim - Will read the article for next time.
Larry - Non-intrusive debugging is for deeply embedded systems, not Raspberry Pi. Read the article and I will get further references.
Tim - We will cover non-intrusive debug next time.
Difference between the two specs:
? - Memory accesses are done differently.
Megan – Are there caches in the system and do they matter?
Richard – JTAG debug is used to bring up a system. Needs external view of memory.
Megan – I rely on not having to worry about things being in cache or flash. Not bringing up hardware anymore but debugging software.
Richard – This is quite ahead in the system debug.
Tim – We want to debug without having GDB server running on the target. In simple systems memory views are the same. There are no MMU.
Tim – What is actually performing a read when requested by the debugger? The hart going through MMU and cache or the system bus? Sounds like the hart requires memory access.
Megan – Could master the bus exactly the same way as a hart would.
Richard – Usually disable cache on small system. Typically use TCM. OK to have CPU trap on bigger systems. You need both access to physical memory and what the processor sees.
Tim – We want both. The debug spec should show how to do that.
Executing Arbitrary instructions:
Tim – Important because of ISA extensions.
Larry – I second that.
Richard – I think it is important. Can implement using GDB stub.
Tim – Nobody disagrees. There should be one stub for OpenOCD that should work with all implementations. That's the point of a spec.
Megan – There should be one OpenOCD implementation for RISC-V. Anyone following the standard should not have to re-implement OpenOCD.
Rex - Why is there a concern about instruction fetch?
Tim – Would like more abstract command and argument to allow different implementations.
Richard – Proposed to reuse the ebreak instruction to allow to jump into ISR.
Debug Monitor Capabilities:
Richard – Provide a map to either hand over control to GDB or jump to debug monitor. Why not reuse breakpoint exception?
Tim – Should there be a command to execute an instruction?
Richard – Added option to run a debug monitor but did not add a command to execute a specific instruction.
Tim – I am not a big fan of using system memory as memory might not be working properly because of the memory controller configuration.
Richard – Starting from bare metal GDB configures the memory controller.
Tim – You might think memory is working but bits might flip because of timing. Using a RAM block for that reason.
Richard – If you define RAM it should be on the system bus. No special wires should be required to access it. Does my proposal comply with Tim's request to run an arbitrary instruction?
Tim - Yes, with the caveat of using system memory.
Richard – Need to be able to catch some interrupts during debug like bus fault.
Vyacheslov – What is debug spec outlines several framework in implementing access. RISC-V covers a huge range of implementations. What is suitable for small systems is not for a large systems. Could introduce extensions for debug capabilities. One axis of extensions could be implementation.
Tim – Concern is that debug tools will only support one specific implementation.
Larry – What is wrong with that approach? Small tool for small processors. Large tool for large multiprocessor systems. A single spec is an admirable goal but we have to be pragmatic. We have been talking about the same things for weeks. Fragment along multicore/multithread.
Vyacheslov – It is not feasible to cover all broad range RISC-V implementations.
Tim – I do not like the idea but will not stand in the way. Will ask people on the mailing list.
Larry – Would be a good use of time. Commercial tools could support one or both. We should do a poll. Will proofread Tim's poll message.
Don – Alex from Segger responded. Do you have any thoughts?
Tim – Will respond on the mailing list.
Don – Interesting comment from Alex about memory access.
Tim Newsome
--
You received this message because you are subscribed to the Google Groups "RISC-V Debug Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to debug+unsubscribe@groups.riscv.org.
To post to this group, send email to de...@groups.riscv.org.
Visit this group at https://groups.google.com/a/groups.riscv.org/group/debug/.
To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/debug/CAJKyqnLiWbDTmFcnVSqMoi%3Dz9-dnqhF-c%2B%3D8kodTcofwtU5iYg%40mail.gmail.com.