> On 2 Dec 2016, at 12:24, Peter Maydell 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 debugg
On 2 December 2016 at 10:12, Liviu Ionescu 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 a
> On 2 Dec 2016, at 11:40, Peter Maydell 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 r
On 1 December 2016 at 19:45, Liviu Ionescu wrote:
>
>> On 1 Dec 2016, at 21:13, Peter Maydell wrote:
>>
>> You need a QCOW2 disk to store the snapshots on, ...
>> Taking savevm snapshots doesn't need any cooperation
>> from the guest OS ..
>> I don't know whether anybody's tested this with M prof
> On 1 Dec 2016, at 21:13, Peter Maydell wrote:
>
> You need a QCOW2 disk to store the snapshots on, ...
> Taking savevm snapshots doesn't need any cooperation
> from the guest OS ..
> I don't know whether anybody's tested this with M profile:
does your Stellaris board support this?
assuming I
On 1 December 2016 at 18:39, Liviu Ionescu wrote:
> as for snapshotting, I'm not sure how I can use this for bare
> metal devices (hints highly appreciated).
You need a QCOW2 disk to store the snapshots on, but it
doesn't actually need to be accessible to the guest system,
so it should work fine
> On 1 Dec 2016, at 16:38, Peter Maydell wrote:
> ... network device backends ... is a fair bit of work.
yes, that's a good point, and I also plan to add Ethernet support to some of my
boards, but I need first to fix some issues that I consider more important,
like Cortex-M system peripherals
On 1 December 2016 at 13:33, Liviu Ionescu wrote:
>> On 1 Dec 2016, at 14:38, Peter Maydell wrote:
>>
>> ... clean up QEMU's code so
>> that it is less interdependent ...
>
> that's a good idea anyway, but this does not address the current issue.
>
> if I'd have a separate library with ARM TCG, f
> On 1 Dec 2016, at 14:38, Peter Maydell wrote:
>
> ... clean up QEMU's code so
> that it is less interdependent ...
that's a good idea anyway, but this does not address the current issue.
if I'd have a separate library with ARM TCG, for Cortex-M emulation I'd
probably write a simple memory m
On 1 December 2016 at 11:54, Liviu Ionescu wrote:
>
>> On 1 Dec 2016, at 10:50, Paolo Bonzini wrote:
>>
>>> But why only linux-user and not full system emulation too?
>>
>> It would simplify the library. The front-end and helpers have some
>> differences
>> between usermode and softmmu, and the
> On 1 Dec 2016, at 10:50, Paolo Bonzini wrote:
>
>> But why only linux-user and not full system emulation too?
>
> It would simplify the library. The front-end and helpers have some
> differences
> between usermode and softmmu, and the latter is much more intertwined with
> the rest of the Q
- Original Message -
> From: "Alessandro Di Federico"
> To: "Paolo Bonzini" , "Liviu Ionescu"
> Cc: "qemu-devel"
> Sent: Thursday, December 1, 2016 12:01:12 AM
> Subject: Re: [Qemu-devel] Support for using TCG frontend as a
On Tue, 29 Nov 2016 17:26:59 +0100
Paolo Bonzini wrote:
> It's pretty clean! I would rather avoid the duplicate enums, possibly
> by automatically generating large parts of ptc.h, but that's pretty
> much it. I see that you check that the constants match (that cpp
> stuff is disgusting :)), and
> On 29 Nov 2016, at 18:26, Paolo Bonzini wrote:
>
> ... It's pretty clean! ...
if you manage to make the TCG frontend as a library, it would be great to check
that it can also be used from C++.
the current QEMU headers prevent this, by using C++ reserved words (like
`class`), which is a re
On 27/11/2016 20:32, Alessandro Di Federico wrote:
>
> I've been investigating the needs of the various projects that might be
> interested in using it and they sum up to the following:
>
> * Be able to load in the same process multiple libtcg-$ARCH.so for
> different architectures.
> * Obtai
Hi all,
QEMU is a great emulator, but in recent years it has also been used
for instrumentation purposes [QIRA,AFL] or as a lifter for static
analysis purposes [rev.ng,angr,libqemu,S²E]. I'd like to hear your
take on the second use case, and the possibility of offering upstream
support for it.
T
16 matches
Mail list logo
