> On 2 Dec 2016, at 12:24, Peter Maydell <peter.mayd...@linaro.org> wrote: > > Right, but if you have a bug which requires your application to > sit there processing for half an hour (or even five minutes) > before it appears, it's nice not to spend that time.
fully agree. for physical targets, the GNU ARM Eclipse debugging plug-ins have a feature called "connect to running target", when the debugger attaches to a live target without any reset or flash reprogramming. > You could surface the basic functionality with a 'snapshot' > button that invoked the monitor "savevm" command, and a > "start from snapshot" that just added '-loadvm snapshotname' to > the QEMU command line. Everything else (including connecting to > gdbstub) should just work as usual. well, yes, something like this can be done, but it is not that simple, normally the debugging plug-ins will reset the board and reprogram the flash, but a similar approach to "connect to running target" can be used. but besides the gui aspects, the deeper conclusion from this discussion is that, regardless the implementation (with the current QEMU very complicated objects, or with the C++ natural objects that I'd like to use), the entire tree of peripherals should be fully serialisable, otherwise the peripheral status cannot be restored correctly. I'll consider this and possibly adjust my current implementation, which does not use links consistently. do you have any other suggestions for making Cortex-M devices 'snaphotable'? (since I understand the ones used in the Stellaris implementation are not). > >> on the other side, what would be really useful for Cortex-M, are >> the instruction and data tracing features available for some >> devices, usually available only with very expensive multi-pin >> JTAG probes on physical devices; were these ARM features considered? > > These are painful to add to TCG (which generally doesn't bother > to keep track of information it doesn't need for execution), > and they'd make things very slow any estimate on how much slower? anyway I think this should be a runtime option, enabled only when really needed; getting the trace output is also expensive on physical targets, so, I think a reasonable speed penalty can be accepted, at least for most Cortex-M devices, which normally run at some tens of MHz. > (plus they're very invasive > changes to the TCG frontend code). So I don't think they're > a bad idea but they're not at the top of my priority list at the > moment. I see. in case you'll reconsider, please let me know, maybe I can help. regards, Liviu
