Re: [Qemu-devel] qemu gdb issue

[Peter Maydell <peter.maydell@linaro.org>]

On 16 March 2012 19:10, Mulyadi Santosa <mulyadi.santosa@gmail.com> wrote:
> On Fri, Mar 16, 2012 at 14:13, Jacques <Jacques@rambo-mes.net> 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