From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:50244) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Qa9py-0007CV-Kn for qemu-devel@nongnu.org; Fri, 24 Jun 2011 13:06:35 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Qa9pr-0003Sy-GM for qemu-devel@nongnu.org; Fri, 24 Jun 2011 13:06:34 -0400 Received: from mail-bw0-f45.google.com ([209.85.214.45]:53303) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Qa9pq-0003SQ-Oi for qemu-devel@nongnu.org; Fri, 24 Jun 2011 13:06:27 -0400 Received: by bwz16 with SMTP id 16so2698565bwz.4 for ; Fri, 24 Jun 2011 10:06:25 -0700 (PDT) From: Max Filippov Date: Fri, 24 Jun 2011 21:06:21 +0400 References: <201106240644.02325.jcmvbkbc@gmail.com> <201106241234.19282.jcmvbkbc@gmail.com> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201106242106.21793.jcmvbkbc@gmail.com> Subject: Re: [Qemu-devel] Actual TB code doesn't look like what was intended (TCG issue)? List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Maydell Cc: qemu-devel@nongnu.org > Here are my rules of thumb for generating code where the code > generated might change based on some bit of CPU state: > > When you are generating code, if the code you generate will > change based on the contents of something in the CPUState struct, > then the bit of CPUState you are looking at has to be one of: > (1) encoded in the TB flags (or tb->pc or tb->cs_base) > (and gen_intermediate_code_internal() must read and > use the value in tb->tb_flags, not the one in env) > (2) always constant for the life of the simulation > (eg env->features if you have some sort of > "target feature support" flags) > (3) specially handled so that when it changes then > all TBs or at least all affected TBs are flushed > (env->breakpoints is in this category), and also > if the change is the result of some instruction then > you must terminate the TB after that instruction. > This is often used for things that rarely change and/or > where you can't fit the whole value into tb_flags. > > The reason for this is that the CPUState you're passed in > is not guaranteed to be the state of the CPU at the PC > which you are starting translation from. > > This is the xtensa port at > http://jcmvbkbc.spb.ru/git/?p=dumb/qemu-xtensa.git;a=shortlog;h=refs/heads/xtensa > right? > > It looks like you're breaking these rules with a lot of > the fields in your DisasContext. (Most obviously, you > need to translate code from tb->pc, not env->pc, and > xtensa_get_ring() and xtensa_get_cring() should not read > from env->sregs[PS]. But you should be clear for every > field in DisasContext which category it falls into.) Peter you are right, I've moved ring/cring into tb_flags and the issue has gone. Thank you. I'd like to document it somewhere in http://wiki.qemu.org/Documentation, can you suggest a good place for it? -- Max