On 16 March 2012 19:10, Mulyadi Santosa <[email protected]> wrote: > On Fri, Mar 16, 2012 at 14:13, Jacques <[email protected]> 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
