[Qemu-devel] qemu gdb issue

[Qemu-devel] qemu gdb issue

[Jacques]

[-- Attachment #1: Type: text/plain, Size: 1363 bytes --]

Hi folks,

I'm busy with a small project and I'm running into problems debugging
qemu. I hope this is the right place to get help.

I'm running an application in qemu through the userspace qemu-i386 and
attaching to the process with gdb. I have pygdb scripts that then
interact with gdb.

The issue is that at some point I want to change $eip and redirect
instruction flow. I then set $eip to the value I need which gives me the
following:

Program received signal SIGSEGV, Segmentation fault.
0x46367046 in ?? ()
(gdb) i r
eax            0x4090ca0e	1083230734
ecx            0x0	0
edx            0x407fed20	1082125600
ebx            0x31704630	829441584
esp            0x407ffe40	0x407ffe40
ebp            0x35704634	0x35704634
esi            0x46327046	1177710662
edi            0x70463370	1883648880
eip            0x46367046	0x46367046
eflags         0x202	[ IF ]
cs             0x23	35
ss             0x2b	43
ds             0x2b	43
es             0x2b	43
fs             0x0	0
gs             0x33	51
(gdb) set $eip=0x08059924
Cannot access memory at address 0x35704638
(gdb) set $eip=0x08059924
(gdb) x/3i $eip
=> 0x8059924:	pop    %ebx
   0x8059925:	pop    %ebp
   0x8059926:	ret
(gdb) si

The si command never returns, I have no idea why this is not working.
Also no idea why the first set fails..

Any help would be massively appreciated!

Kind Regards,
J

[-- Attachment #2: 0x0B03082C.asc --]
[-- Type: application/pgp-keys, Size: 3109 bytes --]

Re: [Qemu-devel] qemu gdb issue

[Mulyadi Santosa]

Hi...

On Thu, Mar 15, 2012 at 23:03, Jacques <Jacques@rambo-mes.net> wrote:
> I'm running an application in qemu through the userspace qemu-i386 and
> attaching to the process with gdb. I have pygdb scripts that then
> interact with gdb.
>
> The issue is that at some point I want to change $eip and redirect
> instruction flow. I then set $eip to the value I need which gives me the
> following:
>
> Program received signal SIGSEGV, Segmentation fault.
> 0x46367046 in ?? ()

I am not keen in this kind of situation,but I think you hit "non
existing" EIP. By that, I mean  maybe you think such EIP truly exist
(based on ELF info perhaps?), but in reality since qemu user mode do
dynamic translations and not really following ELF offset, you got
segfault.


-- 
regards,

Mulyadi Santosa
Freelance Linux trainer and consultant

blog: the-hydra.blogspot.com
training: mulyaditraining.blogspot.com

Re: [Qemu-devel] qemu gdb issue

[Jacques]

[-- Attachment #1: Type: text/plain, Size: 999 bytes --]

Hi Mulyadi,

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.

On 03/15/2012 07:13 PM, Mulyadi Santosa wrote:
> Hi...
> 
> On Thu, Mar 15, 2012 at 23:03, Jacques <Jacques@rambo-mes.net> wrote:
>> I'm running an application in qemu through the userspace qemu-i386 and
>> attaching to the process with gdb. I have pygdb scripts that then
>> interact with gdb.
>>
>> The issue is that at some point I want to change $eip and redirect
>> instruction flow. I then set $eip to the value I need which gives me the
>> following:
>>
>> Program received signal SIGSEGV, Segmentation fault.
>> 0x46367046 in ?? ()
> 
> I am not keen in this kind of situation,but I think you hit "non
> existing" EIP. By that, I mean  maybe you think such EIP truly exist
> (based on ELF info perhaps?), but in reality since qemu user mode do
> dynamic translations and not really following ELF offset, you got
> segfault.
> 
> 

[-- Attachment #2: 0x0B03082C.asc --]
[-- Type: application/pgp-keys, Size: 3109 bytes --]

Re: [Qemu-devel] qemu gdb issue

[Mulyadi Santosa]

Hi Jacques...

On Fri, Mar 16, 2012 at 14:13, Jacques <Jacques@rambo-mes.net> wrote:
> Hi Mulyadi,
>
> 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.

Folks with better qemu gdbstub understanding certainly could offer
better explanation.

-- 
regards,

Mulyadi Santosa
Freelance Linux trainer and consultant

blog: the-hydra.blogspot.com
training: mulyaditraining.blogspot.com

Re: [Qemu-devel] qemu gdb issue

[Peter Maydell]

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