From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:56483) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S8cke-0001PI-JR for qemu-devel@nongnu.org; Fri, 16 Mar 2012 15:23:49 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1S8ckc-0002ZM-Gr for qemu-devel@nongnu.org; Fri, 16 Mar 2012 15:23:48 -0400 Received: from mail-iy0-f173.google.com ([209.85.210.173]:61111) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S8ckc-0002Vc-CN for qemu-devel@nongnu.org; Fri, 16 Mar 2012 15:23:46 -0400 Received: by iafj26 with SMTP id j26so6515598iaf.4 for ; Fri, 16 Mar 2012 12:23:43 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: References: <4F6212C2.4030104@rambo-mes.net> <4F62E808.4070002@rambo-mes.net> Date: Fri, 16 Mar 2012 19:23:43 +0000 Message-ID: From: Peter Maydell Content-Type: text/plain; charset=UTF-8 Subject: Re: [Qemu-devel] qemu gdb issue List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Mulyadi Santosa Cc: Jacques , qemu-devel@nongnu.org On 16 March 2012 19:10, Mulyadi Santosa wrote: > On Fri, Mar 16, 2012 at 14:13, Jacques wrote: >> I see what you mean. How do I know if this is happening? When I do 'x/i >> $eip' I get a completely sane result with exactly the instructions I want. > > Alright, that confuses me too. > > The best other explanation I can offer is that if you arbitrarily set > EIP into any address, you might violate the Qemu translation block > (TB) jump (between TB to TB). Maybe you think you correctly hit one, > but by the time it is going to be executed, it is flushed by > translated block cache, so it is read again and re-translated, thus > getting another address in TB cache. This ought not to cause a problem -- when the user sets PC via the gdb stub the next thing that should happen is we try to execute that instruction, which should cause us either (a) to pull the right TB out of the cache or (b) to translate it from scratch. My guess is that this is gdb being too clever for its own good: (gdb) set $eip=0x08059924 Cannot access memory at address 0x35704638 That address is (according to the register dump) EBP+4. Perhaps there is some debug info or similar that makes gdb think that at this point in time EIP is really being held in memory at EBP+4. So when you try to set EIP it's (trying to) write to memory... You could confirm this hypothesis by turning on gdb's logging of remote protocol packets (via "set debug remote 1") and then looking at what it actually does when you try to set $eip in this situation. (Warning: this will require you to decode the protocol packets manually which is not for the faint of heart, although they are all documented in the gdb manual.) -- PMM