Please see more embedded comments.
On Tue, Apr 29, 2014 at 11:47 PM, Stefan Kristiansson < [email protected]> wrote: > On Tue, Apr 29, 2014 at 3:48 PM, Jose Teixeira de Sousa <[email protected]> > wrote: > > Hi Stefan, > > > > see embedded comments: > > > >> > >> > >> mor1kx has a debug port, it's not specifically tied to adbg, but > >> that's likely what will be used. > >> What problem did you experience and could you provide a testcase where > it > >> fails. > > > > > > Use the DE0 nano board or this branch ( > https://github.com/openrisc/orpsoc-cores/pull/35) with Icarus or > Verilator (which I have > > not had time to improve yet but works ok on 32 bit PCs and has not yet > been > > upgraded to 64-bit machines due to the elf loader problem recently > solved). > > > > If you use either of these you will see that breakpoints and namely Step > vs. > > Next is not working properly. It does not do Next well. > > > > Both breakpoints and single stepping works for me on the de0 nano > board with mor1kx, could you please be more precise? > https://github.com/openrisc/orpsoc-cores/pull/35 is using or1200, I > can't see how that's going to help debug an issue with mor1kx? > > Please you need just switch it to mor1kx in orpsoc-defines.v. I left it to OR1200 because that what last was working for me. Please confirm you see the issue. You need to create a function f() and set a breakpoint where this function is called, say line 10. (gdb) break 10 It actually stops at line 10 (gdb) next Here instead of moving over f and stopping again at line 11 it actually enters inside function f(), that is, it behaves sort of like ""step" instead of like "next". I hope this is clear now and that you will be able to reproduce it. Please let me know. > > > >> > >> What are the problems with verilator and adbg? > >> > > > > If you activate the Verilator switch to give all warnings you 'll see > many > > unacceptable stuff that backend ASIC engineers will simply refuse to go > > forward with it. Moreover ADBG is a dead body in the chip if you're not > > doing debug, which is not really compatible with a low energy approach, > or > > complicate matters with gate clocking to power it down etc. > > > > What would you like to use as an alternative then? > > We could use a JTAG peripheral or existing RS232 UART and send the GDB commands directly to the CPU. A simple gdb stub (or server could be written) to conduct the debug process. LM32 uses a scheme like this. Since gdb stubs will change the code of the program to implement breakpoints using software exception support for self modifying code is needed. However, the recent work on atomic loads and stores may provide adequate support for this (make sure the memory is not read before the stub actually modifies it). > > In general it would be preferable to solve these sanitary issues first > > (debug and profiling) before addressing more complex issues such as > > multicore approaches. I am not by any means diminishing the tremendous > stuff > > that Stefan W. has just presented on the multicore front which certainly > > very cool, but I always enjoy playing the janitor-in-chief role :-) > > > > Sure, but then we need a clear picture of what the actual problem is. > > I hope you have a clearer picture now and appreciate your feedback. > Stefan > -- Jose T. de Sousa, PhD Office: +351 213 100 213 R. Alves Redol 9 1000-029 Lisboa Portugal
_______________________________________________ OpenRISC mailing list [email protected] http://lists.openrisc.net/listinfo/openrisc
