On 2 December 2016 at 10:12, Liviu Ionescu <i...@livius.net> wrote: > 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.
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. > 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. 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. > 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 (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. thanks -- PMM
