reverse execution

reverse execution

[ishare]

    I record at 0x40000000 , then I nexti 10 instructions , then I want reverse execute 
    these 10 instructions one by one, So I type reverse-nexti ,but unexpectly ,gdb directly
    goes back to the addresss 0x40000000 ,where I start record .

    What I need is 10->9->8->7->6->5->4->3->2->1 ,not execute again from begin to end .

    How can I do for this ?

    thanks in advance ! 

Re: reverse execution

[Jan Kratochvil]

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

On Mon, 08 Apr 2013 16:34:37 +0200, ishare wrote:
> I record at 0x40000000 , then I nexti 10 instructions , then I want reverse execute 
> these 10 instructions one by one, So I type reverse-nexti ,but unexpectly ,gdb directly
> goes back to the addresss 0x40000000 ,where I start record .
> 
> What I need is 10->9->8->7->6->5->4->3->2->1 ,not execute again from begin to end .

It is safer during troubleshooting to use *stepi instead of *nexti (where
there is no difference as there is no call instruction).

It works for me with 7.5.1 so it would be needed to have a reproducer.

Additionally there ware some 7.6 (pre-release available now) fixes to these
issues but it should not affect this case as long as there are no calls.


Regards,
Jan


GNU gdb (GDB) 7.5.1.20130125-cvs
Copyright (C) 2012 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-unknown-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /home/jkratoch/t/nops...done.
(gdb) disas _start
Dump of assembler code for function _start:
   0x00000000004000d4 <+0>:	nop
   0x00000000004000d5 <+1>:	nop
   0x00000000004000d6 <+2>:	nop
   0x00000000004000d7 <+3>:	nop
   0x00000000004000d8 <+4>:	nop
   0x00000000004000d9 <+5>:	nop
   0x00000000004000da <+6>:	nop
   0x00000000004000db <+7>:	nop
   0x00000000004000dc <+8>:	nop
   0x00000000004000dd <+9>:	nop
   0x00000000004000de <+10>:	int3   
End of assembler dump.
(gdb) info files 
Symbols from "/home/jkratoch/t/nops".
Local exec file:
	`/home/jkratoch/t/nops', file type elf64-x86-64.
	Entry point: 0x4000d4
	0x00000000004000b0 - 0x00000000004000d4 is .note.gnu.build-id
	0x00000000004000d4 - 0x00000000004000df is .text
(gdb) b *0x4000d4
Breakpoint 1 at 0x4000d4: file nops.S, line 2.
(gdb) r
Starting program: /home/jkratoch/t/nops 
warning: no loadable sections found in added symbol-file system-supplied DSO at 0x7ffff7ffd000

Breakpoint 1, _start () at nops.S:2
2	nop
(gdb) record 
(gdb) nexti
3	nop
(gdb) 
4	nop
(gdb) 
5	nop
(gdb) 
6	nop
(gdb) 
7	nop
(gdb) 
8	nop
(gdb) 
9	nop
(gdb) 
10	nop
(gdb) 
11	nop
(gdb) 
12	int3
(gdb) reverse-nexti
11	nop
(gdb) 
10	nop
(gdb) 
9	nop
(gdb) 
8	nop
(gdb) 
7	nop
(gdb) 
6	nop
(gdb) 
5	nop
(gdb) 
4	nop
(gdb) 
3	nop
(gdb) 

No more reverse-execution history.
_start () at nops.S:2
2	nop
(gdb) 

[-- Attachment #2: nops.S --]
[-- Type: text/plain, Size: 67 bytes --]

_start: .globl _start
nop
nop
nop
nop
nop
nop
nop
nop
nop
nop
int3

reverse execution

[burlen]

Is it possible to use reverse execution features on x86-64 linux 
platform? I turned it on bad things happened. namely sigtrap then 
sigabrt. it spit out these messages:

Process record doesn't support instruction 0xf10 at address 0x7fffdda0dc77.
Process record: failed to record execution log.

My session follows. Does this mean reverse execution isn't going to work 
on this platform? or perhaps I have done something wrong in my attempt 
to use the feature?

Thanks
Burlen


(gdb) run
Starting program: /home/burlen/ext/ParaView/PV3-3.7/bin/pvserver
[Thread debugging using libthread_db enabled]
Listen on port: 11111
Waiting for client...
Waiting for server...
Client connected.
^C
Program received signal SIGINT, Interrupt.
0x00007fffe31a66f3 in select () from /lib/libc.so.6
(gdb) br vtkOOCFieldTracer::OOCIntegrateOne
Breakpoint 1 at 0x7fffdda0b591: file 
/home/burlen/ext/ParaView/SciVisToolKit/vtkOOCFieldTracer.cxx, line 447.
(gdb) cont
Continuing.

Breakpoint 1, vtkOOCFieldTracer::OOCIntegrateOne (this=0xa77570, 
oocR=0x1fbff10, fieldName=0xed88b8 "vi", line=0x1fd2020, 
tcon=0x7fffffffc480) at 
/home/burlen/ext/ParaView/SciVisToolKit/vtkOOCFieldTracer.cxx:447
447       int w=0;
(gdb) target record
(gdb) disable 1
(gdb) cont
Continuing.
Process record doesn't support instruction 0xf10 at address 0x7fffdda0dc77.
Process record: failed to record execution log.

Program received signal SIGTRAP, Trace/breakpoint trap.
0x00007fffdda0dc76 in FieldLine::GetSeedPoint (this=0x1fd2020, 
p=0x7fffffffc2e0) at /home/burlen/ext/ParaView/SciVisToolKit/FieldLine.h:113
113         p[0]=this->Seed[0];
(gdb) cont
Continuing.
Process record doesn't support instruction 0xf10 at address 0x7fffdda0dc77.
Process record: failed to record execution log.

Program received signal SIGABRT, Aborted.
0x00007fffdda0dc76 in FieldLine::GetSeedPoint (this=0x1fd2020, 
p=0x7fffffffc2e0) at /home/burlen/ext/ParaView/SciVisToolKit/FieldLine.h:113
113         p[0]=this->Seed[0];
(gdb)

Re: reverse execution

[Michael Snyder]

burlen wrote:
> Is it possible to use reverse execution features on x86-64 linux 
> platform? I turned it on bad things happened. namely sigtrap then 
> sigabrt. it spit out these messages:
> 
> Process record doesn't support instruction 0xf10 at address 0x7fffdda0dc77.
> Process record: failed to record execution log.
> 
> My session follows. Does this mean reverse execution isn't going to work 
> on this platform? or perhaps I have done something wrong in my attempt 
> to use the feature?
> 
> Thanks
> Burlen
> 
> 
> (gdb) run
> Starting program: /home/burlen/ext/ParaView/PV3-3.7/bin/pvserver
> [Thread debugging using libthread_db enabled]
> Listen on port: 11111
> Waiting for client...
> Waiting for server...
> Client connected.
> ^C
> Program received signal SIGINT, Interrupt.
> 0x00007fffe31a66f3 in select () from /lib/libc.so.6
> (gdb) br vtkOOCFieldTracer::OOCIntegrateOne
> Breakpoint 1 at 0x7fffdda0b591: file 
> /home/burlen/ext/ParaView/SciVisToolKit/vtkOOCFieldTracer.cxx, line 447.
> (gdb) cont
> Continuing.
> 
> Breakpoint 1, vtkOOCFieldTracer::OOCIntegrateOne (this=0xa77570, 
> oocR=0x1fbff10, fieldName=0xed88b8 "vi", line=0x1fd2020, 
> tcon=0x7fffffffc480) at 
> /home/burlen/ext/ParaView/SciVisToolKit/vtkOOCFieldTracer.cxx:447
> 447       int w=0;
> (gdb) target record
> (gdb) disable 1
> (gdb) cont
> Continuing.
> Process record doesn't support instruction 0xf10 at address 0x7fffdda0dc77.
> Process record: failed to record execution log.
> 
> Program received signal SIGTRAP, Trace/breakpoint trap.
> 0x00007fffdda0dc76 in FieldLine::GetSeedPoint (this=0x1fd2020, 
> p=0x7fffffffc2e0) at /home/burlen/ext/ParaView/SciVisToolKit/FieldLine.h:113
> 113         p[0]=this->Seed[0];
> (gdb) cont
> Continuing.
> Process record doesn't support instruction 0xf10 at address 0x7fffdda0dc77.
> Process record: failed to record execution log.
> 
> Program received signal SIGABRT, Aborted.
> 0x00007fffdda0dc76 in FieldLine::GetSeedPoint (this=0x1fd2020, 
> p=0x7fffffffc2e0) at /home/burlen/ext/ParaView/SciVisToolKit/FieldLine.h:113
> 113         p[0]=this->Seed[0];
> (gdb)

It's believed to be working on x86_64, but it's a brand new
feature, so bugs are expected.

I assume you are using gdb-7.0?

Can you share your source code with us?

Re: reverse execution

[Daniel Jacobowitz]

On Fri, Oct 16, 2009 at 02:01:57PM -0700, Michael Snyder wrote:
> It's believed to be working on x86_64, but it's a brand new
> feature, so bugs are expected.

IIUC, it's not too useful on x86_64 - with no (or very limited) SSE
support.  That's probably what this is, but I don't claim to decode
x86 opcodes in my head :-)

-- 
Daniel Jacobowitz
CodeSourcery

Re: reverse execution

[Jiang Jilin]

On Sat, Oct 17, 2009 at 4:34 AM, burlen <burlen.loring@gmail.com> wrote:
> Is it possible to use reverse execution features on x86-64 linux platform? I
> turned it on bad things happened. namely sigtrap then sigabrt. it spit out
> these messages:
>
> Process record doesn't support instruction 0xf10 at address 0x7fffdda0dc77.
> Process record: failed to record execution log.

I checked the opcode 0x0f10, it seems that it hasn't been supported so far,
either on x86-32 or x86-64.  I'm working on it.

Thank you for reporting!


To Hui and Michael :

Sorry, I'm a bit busy for looking for jobs these days, so I've to
delay the work for
MMX support . And now, I think I should add opcode 0x0f10 support and other
2-byte opcodes at first, because they seems more easier to implement.
Any questions
please tell me :)

Thanks!

Jiang

> My session follows. Does this mean reverse execution isn't going to work on
> this platform? or perhaps I have done something wrong in my attempt to use
> the feature?
>
> Thanks
> Burlen
>
>
> (gdb) run
> Starting program: /home/burlen/ext/ParaView/PV3-3.7/bin/pvserver
> [Thread debugging using libthread_db enabled]
> Listen on port: 11111
> Waiting for client...
> Waiting for server...
> Client connected.
> ^C
> Program received signal SIGINT, Interrupt.
> 0x00007fffe31a66f3 in select () from /lib/libc.so.6
> (gdb) br vtkOOCFieldTracer::OOCIntegrateOne
> Breakpoint 1 at 0x7fffdda0b591: file
> /home/burlen/ext/ParaView/SciVisToolKit/vtkOOCFieldTracer.cxx, line 447.
> (gdb) cont
> Continuing.
>
> Breakpoint 1, vtkOOCFieldTracer::OOCIntegrateOne (this=0xa77570,
> oocR=0x1fbff10, fieldName=0xed88b8 "vi", line=0x1fd2020,
> tcon=0x7fffffffc480) at
> /home/burlen/ext/ParaView/SciVisToolKit/vtkOOCFieldTracer.cxx:447
> 447       int w=0;
> (gdb) target record
> (gdb) disable 1
> (gdb) cont
> Continuing.
> Process record doesn't support instruction 0xf10 at address 0x7fffdda0dc77.
> Process record: failed to record execution log.
>
> Program received signal SIGTRAP, Trace/breakpoint trap.
> 0x00007fffdda0dc76 in FieldLine::GetSeedPoint (this=0x1fd2020,
> p=0x7fffffffc2e0) at /home/burlen/ext/ParaView/SciVisToolKit/FieldLine.h:113
> 113         p[0]=this->Seed[0];
> (gdb) cont
> Continuing.
> Process record doesn't support instruction 0xf10 at address 0x7fffdda0dc77.
> Process record: failed to record execution log.
>
> Program received signal SIGABRT, Aborted.
> 0x00007fffdda0dc76 in FieldLine::GetSeedPoint (this=0x1fd2020,
> p=0x7fffffffc2e0) at /home/burlen/ext/ParaView/SciVisToolKit/FieldLine.h:113
> 113         p[0]=this->Seed[0];
> (gdb)
>
>
>



-- 
Jiang

Re: reverse execution

[Hui Zhu]

Thanks Jilin,

Sorry I made a mistake when we told about it.  I want to say 0xf10
series insn (they seems called sse insn), but I said mmx insn.

These 0xf10 insn seems control the xmm reg, you can see the values of
these reg whith gdb cmd "info info all-registers".

Hui


On Sun, Oct 18, 2009 at 09:02, Jiang Jilin <freephp@gmail.com> wrote:
> On Sat, Oct 17, 2009 at 4:34 AM, burlen <burlen.loring@gmail.com> wrote:
>> Is it possible to use reverse execution features on x86-64 linux platform? I
>> turned it on bad things happened. namely sigtrap then sigabrt. it spit out
>> these messages:
>>
>> Process record doesn't support instruction 0xf10 at address 0x7fffdda0dc77.
>> Process record: failed to record execution log.
>
> I checked the opcode 0x0f10, it seems that it hasn't been supported so far,
> either on x86-32 or x86-64.  I'm working on it.
>
> Thank you for reporting!
>
>
> To Hui and Michael :
>
> Sorry, I'm a bit busy for looking for jobs these days, so I've to
> delay the work for
> MMX support . And now, I think I should add opcode 0x0f10 support and other
> 2-byte opcodes at first, because they seems more easier to implement.
> Any questions
> please tell me :)
>
> Thanks!
>
> Jiang
>
>> My session follows. Does this mean reverse execution isn't going to work on
>> this platform? or perhaps I have done something wrong in my attempt to use
>> the feature?
>>
>> Thanks
>> Burlen
>>
>>
>> (gdb) run
>> Starting program: /home/burlen/ext/ParaView/PV3-3.7/bin/pvserver
>> [Thread debugging using libthread_db enabled]
>> Listen on port: 11111
>> Waiting for client...
>> Waiting for server...
>> Client connected.
>> ^C
>> Program received signal SIGINT, Interrupt.
>> 0x00007fffe31a66f3 in select () from /lib/libc.so.6
>> (gdb) br vtkOOCFieldTracer::OOCIntegrateOne
>> Breakpoint 1 at 0x7fffdda0b591: file
>> /home/burlen/ext/ParaView/SciVisToolKit/vtkOOCFieldTracer.cxx, line 447.
>> (gdb) cont
>> Continuing.
>>
>> Breakpoint 1, vtkOOCFieldTracer::OOCIntegrateOne (this=0xa77570,
>> oocR=0x1fbff10, fieldName=0xed88b8 "vi", line=0x1fd2020,
>> tcon=0x7fffffffc480) at
>> /home/burlen/ext/ParaView/SciVisToolKit/vtkOOCFieldTracer.cxx:447
>> 447       int w=0;
>> (gdb) target record
>> (gdb) disable 1
>> (gdb) cont
>> Continuing.
>> Process record doesn't support instruction 0xf10 at address 0x7fffdda0dc77.
>> Process record: failed to record execution log.
>>
>> Program received signal SIGTRAP, Trace/breakpoint trap.
>> 0x00007fffdda0dc76 in FieldLine::GetSeedPoint (this=0x1fd2020,
>> p=0x7fffffffc2e0) at /home/burlen/ext/ParaView/SciVisToolKit/FieldLine.h:113
>> 113         p[0]=this->Seed[0];
>> (gdb) cont
>> Continuing.
>> Process record doesn't support instruction 0xf10 at address 0x7fffdda0dc77.
>> Process record: failed to record execution log.
>>
>> Program received signal SIGABRT, Aborted.
>> 0x00007fffdda0dc76 in FieldLine::GetSeedPoint (this=0x1fd2020,
>> p=0x7fffffffc2e0) at /home/burlen/ext/ParaView/SciVisToolKit/FieldLine.h:113
>> 113         p[0]=this->Seed[0];
>> (gdb)
>>
>>
>>
>
>
>
> --
> Jiang
>

Re: reverse execution

[Jiang Jilin]

On Sun, Oct 18, 2009 at 10:45 AM, Hui Zhu <teawater@gmail.com> wrote:
> Thanks Jilin,
>
> Sorry I made a mistake when we told about it.  I want to say 0xf10
> series insn (they seems called sse insn), but I said mmx insn.

Aha, I misunderstood what you said. I take a glance at the specific and
find they are relevant with mmx, so you are right. :)

> These 0xf10 insn seems control the xmm reg, you can see the values of
> these reg whith gdb cmd "info info all-registers".

Yeah, It seems I cannot delay the work for mmx insn. :)

Thanks Hui.

> Hui
>
>
> On Sun, Oct 18, 2009 at 09:02, Jiang Jilin <freephp@gmail.com> wrote:
>> On Sat, Oct 17, 2009 at 4:34 AM, burlen <burlen.loring@gmail.com> wrote:
>>> Is it possible to use reverse execution features on x86-64 linux platform? I
>>> turned it on bad things happened. namely sigtrap then sigabrt. it spit out
>>> these messages:
>>>
>>> Process record doesn't support instruction 0xf10 at address 0x7fffdda0dc77.
>>> Process record: failed to record execution log.
>>
>> I checked the opcode 0x0f10, it seems that it hasn't been supported so far,
>> either on x86-32 or x86-64.  I'm working on it.
>>
>> Thank you for reporting!
>>
>>
>> To Hui and Michael :
>>
>> Sorry, I'm a bit busy for looking for jobs these days, so I've to
>> delay the work for
>> MMX support . And now, I think I should add opcode 0x0f10 support and other
>> 2-byte opcodes at first, because they seems more easier to implement.
>> Any questions
>> please tell me :)
>>
>> Thanks!
>>
>> Jiang
>>
>>> My session follows. Does this mean reverse execution isn't going to work on
>>> this platform? or perhaps I have done something wrong in my attempt to use
>>> the feature?
>>>
>>> Thanks
>>> Burlen
>>>
>>>
>>> (gdb) run
>>> Starting program: /home/burlen/ext/ParaView/PV3-3.7/bin/pvserver
>>> [Thread debugging using libthread_db enabled]
>>> Listen on port: 11111
>>> Waiting for client...
>>> Waiting for server...
>>> Client connected.
>>> ^C
>>> Program received signal SIGINT, Interrupt.
>>> 0x00007fffe31a66f3 in select () from /lib/libc.so.6
>>> (gdb) br vtkOOCFieldTracer::OOCIntegrateOne
>>> Breakpoint 1 at 0x7fffdda0b591: file
>>> /home/burlen/ext/ParaView/SciVisToolKit/vtkOOCFieldTracer.cxx, line 447.
>>> (gdb) cont
>>> Continuing.
>>>
>>> Breakpoint 1, vtkOOCFieldTracer::OOCIntegrateOne (this=0xa77570,
>>> oocR=0x1fbff10, fieldName=0xed88b8 "vi", line=0x1fd2020,
>>> tcon=0x7fffffffc480) at
>>> /home/burlen/ext/ParaView/SciVisToolKit/vtkOOCFieldTracer.cxx:447
>>> 447       int w=0;
>>> (gdb) target record
>>> (gdb) disable 1
>>> (gdb) cont
>>> Continuing.
>>> Process record doesn't support instruction 0xf10 at address 0x7fffdda0dc77.
>>> Process record: failed to record execution log.
>>>
>>> Program received signal SIGTRAP, Trace/breakpoint trap.
>>> 0x00007fffdda0dc76 in FieldLine::GetSeedPoint (this=0x1fd2020,
>>> p=0x7fffffffc2e0) at /home/burlen/ext/ParaView/SciVisToolKit/FieldLine.h:113
>>> 113         p[0]=this->Seed[0];
>>> (gdb) cont
>>> Continuing.
>>> Process record doesn't support instruction 0xf10 at address 0x7fffdda0dc77.
>>> Process record: failed to record execution log.
>>>
>>> Program received signal SIGABRT, Aborted.
>>> 0x00007fffdda0dc76 in FieldLine::GetSeedPoint (this=0x1fd2020,
>>> p=0x7fffffffc2e0) at /home/burlen/ext/ParaView/SciVisToolKit/FieldLine.h:113
>>> 113         p[0]=this->Seed[0];
>>> (gdb)
>>>
>>>
>>>
>>
>>
>>
>> --
>> Jiang
>>
>



-- 
Jiang

Re: reverse execution

[Michael Snyder]

Jiang Jilin wrote:
> On Sun, Oct 18, 2009 at 10:45 AM, Hui Zhu <teawater@gmail.com> wrote:
>> Thanks Jilin,
>>
>> Sorry I made a mistake when we told about it.  I want to say 0xf10
>> series insn (they seems called sse insn), but I said mmx insn.
> 
> Aha, I misunderstood what you said. I take a glance at the specific and
> find they are relevant with mmx, so you are right. :)
> 
>> These 0xf10 insn seems control the xmm reg, you can see the values of
>> these reg whith gdb cmd "info info all-registers".
> 
> Yeah, It seems I cannot delay the work for mmx insn. :)

Don't forget that Paawan Oza has already said he was going to
work on the reverse MMX support.  Wouldn't want to see you two
guys duplicating effort...

Re: reverse execution

[Hui Zhu]

Hi Oza,

are you working on or done with sse insn?

Thanks,
Hui

On Sun, Oct 18, 2009 at 11:55, Michael Snyder <msnyder@vmware.com> wrote:
> Jiang Jilin wrote:
>>
>> On Sun, Oct 18, 2009 at 10:45 AM, Hui Zhu <teawater@gmail.com> wrote:
>>>
>>> Thanks Jilin,
>>>
>>> Sorry I made a mistake when we told about it.  I want to say 0xf10
>>> series insn (they seems called sse insn), but I said mmx insn.
>>
>> Aha, I misunderstood what you said. I take a glance at the specific and
>> find they are relevant with mmx, so you are right. :)
>>
>>> These 0xf10 insn seems control the xmm reg, you can see the values of
>>> these reg whith gdb cmd "info info all-registers".
>>
>> Yeah, It seems I cannot delay the work for mmx insn. :)
>
> Don't forget that Paawan Oza has already said he was going to
> work on the reverse MMX support.  Wouldn't want to see you two
> guys duplicating effort...
>
>