> On 2 Dec 2016, at 11:40, Peter Maydell <peter.mayd...@linaro.org> wrote: > >> ... integrate this feature in the usual debugging workflow. > > The most useful approach is that you can set up a complicated > situation (eg "boot my embedded RTOS, start application"), > snapshot at that point, and then you can repeatedly restart > debugging from the snapshot without having to take ages going > through the bootup process each time. (Particularly useful if > you turn on heavyweight tracing which can turn bootup from > "fairly fast" to "incredibly slow".)
I see your point, and I'm convinced that for your use cases booting linux and starting applications is a big deal of effort. for the bare metal use cases, "going through the bootup process" is quite lightwheight, setting a few registers and the application starts. as for integration with the current workflow, it might be done, but it requires quite a lot of efforts, and the results are only for a very limited audience, if any. 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? --- to summarise, the requirements for emulating Cortex-M devices are much, much lower than for your current large targets using OSes. as a result, I'm seriously considering simplifying the GNU ARM Eclipse QEMU setup and tapping directly into the TCG, so packing it as a library will definitely be a useful feature. regards, Liviu
