[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] Support for using TCG frontend as a library
From: |
Liviu Ionescu |
Subject: |
Re: [Qemu-devel] Support for using TCG frontend as a library |
Date: |
Fri, 2 Dec 2016 12:51:02 +0200 |
> On 2 Dec 2016, at 12:24, Peter Maydell <address@hidden> 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
- Re: [Qemu-devel] Support for using TCG frontend as a library, (continued)
- Re: [Qemu-devel] Support for using TCG frontend as a library, Liviu Ionescu, 2016/12/01
- Re: [Qemu-devel] Support for using TCG frontend as a library, Peter Maydell, 2016/12/01
- Re: [Qemu-devel] Support for using TCG frontend as a library, Liviu Ionescu, 2016/12/01
- Re: [Qemu-devel] Support for using TCG frontend as a library, Peter Maydell, 2016/12/01
- Re: [Qemu-devel] Support for using TCG frontend as a library, Liviu Ionescu, 2016/12/01
- Re: [Qemu-devel] Support for using TCG frontend as a library, Peter Maydell, 2016/12/01
- Re: [Qemu-devel] Support for using TCG frontend as a library, Liviu Ionescu, 2016/12/01
- Re: [Qemu-devel] Support for using TCG frontend as a library, Peter Maydell, 2016/12/02
- Re: [Qemu-devel] Support for using TCG frontend as a library, Liviu Ionescu, 2016/12/02
- Re: [Qemu-devel] Support for using TCG frontend as a library, Peter Maydell, 2016/12/02
- Re: [Qemu-devel] Support for using TCG frontend as a library,
Liviu Ionescu <=