[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] Any better way to access CPUArchState in vl.c?
From: |
Andreas Färber |
Subject: |
Re: [Qemu-devel] Any better way to access CPUArchState in vl.c? |
Date: |
Tue, 19 Jun 2012 14:12:41 +0200 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120421 Thunderbird/12.0 |
Am 19.06.2012 13:54, schrieb 陳韋任 (Wei-Ren Chen):
>> If you only have one CPU then using first_cpu->some_field1 should be
>> almost as easy. :)
>
> I am afraid first_cpu (CPUArchState) is got poisoned, too. :/
> Even I comment out CPUArchState from poison.h,
>
> --- vl.c
> extern CPUArchState *first_cpu;
>
> static void main_loop(void)
> {
> ... snip ...
>
> printf("%d", first_cpu->created);
> }
> ---
>
> I still get compilation error below,
>
> ---
> /tmp/chenwj/qemu/vl.c:1548:20: error: expected '=', ',', ';', 'asm' or
> '__attribute__' before '*' token
> /tmp/chenwj/qemu/vl.c: In function 'main_loop':
> /tmp/chenwj/qemu/vl.c:1568:18: error: 'first_cpu' undeclared (first use in
> this function)
> ---
>
> Any thought on what I am missing? Thanks.
Sorry, my mistake: vl.c is not compiled per-target like I thought but
per target_phys_addr_t in libhwX, thus it cannot access cpu.h or
CPUArchState (only CPUState). That means evaluations of fields in
CPUARMState need to be done in target-arm/ and you might want to check
the Notifiers or in the worst case _atexit() to hook some callback
function up. With QOM CPUState there's finalizers in theory but I don't
think they get called yet for anything except linux-user thread exit.
Andreas
--
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg