Reverse Debugging Headaches

Reverse Debugging Headaches

[Sean Soria]

Whenever I try to reverse debug I break into the program, set target
record and then continue. I immediately hit some sort of simd
instruction (in things like strlen in libc) or unsupported ioctl call.
 Is there any way around these issues?

Re: Reverse Debugging Headaches

[Hui Zhu]

record save #If you still need the prev log, this cmd will save the log
record stop #This cmd will stop the record target
stepi #step over the insn  that prec didn't support

record #continue record

Hui

On Sun, Jan 10, 2010 at 14:03, Sean Soria <sean.soria@gmail.com> wrote:
> Whenever I try to reverse debug I break into the program, set target
> record and then continue. I immediately hit some sort of simd
> instruction (in things like strlen in libc) or unsupported ioctl call.
>  Is there any way around these issues?
>

Re: Reverse Debugging Headaches

[Michael Snyder]

Sean Soria wrote:
> Whenever I try to reverse debug I break into the program, set target
> record and then continue. I immediately hit some sort of simd
> instruction (in things like strlen in libc) or unsupported ioctl call.
>  Is there any way around these issues?

Shouldn't happen.  What version gdb?  What linux?

Re: Reverse Debugging Headaches

[Sean Soria]

gdb 7.0 on Ubuntu Karmic.

On Mon, Jan 11, 2010 at 10:47 AM, Michael Snyder <msnyder@vmware.com> wrote:
> Sean Soria wrote:
>>
>> Whenever I try to reverse debug I break into the program, set target
>> record and then continue. I immediately hit some sort of simd
>> instruction (in things like strlen in libc) or unsupported ioctl call.
>>  Is there any way around these issues?
>
> Shouldn't happen.  What version gdb?  What linux?
>
>

Re: Reverse Debugging Headaches

[Jan Kratochvil]

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

On Mon, 11 Jan 2010 19:47:13 +0100, Michael Snyder wrote:
> Sean Soria wrote:
> >Whenever I try to reverse debug I break into the program, set target
> >record and then continue. I immediately hit some sort of simd
> >instruction (in things like strlen in libc) or unsupported ioctl call.
> > Is there any way around these issues?
> 
> Shouldn't happen.  What version gdb?  What linux?

gdb 7.0.50.20100111-cvs Fedora 12:

kernel-2.6.32.1-9.fc13.x86_64 -> x86_64 gdb -> x86_64 inferior:
(gdb) start
Temporary breakpoint 1 at 0x400640: file threadit.c, line 40.
Starting program: /home/jkratoch/t/threadit 
[Thread debugging using libthread_db enabled]
Temporary breakpoint 1, main () at threadit.c:40
40	  i = pthread_create (&thread1, NULL, start, NULL);	/* create1 */
(gdb) record
(gdb) c
Continuing.
warning: Process record ignores the memory change of instruction at address 0x362de0db46 because it can't get the value of the segment register.
[...]
warning: Process record ignores the memory change of instruction at address 0x362e274d46 because it can't get the value of the segment register.
Process record doesn't support instruction 0xf6e at address 0x362e281a32.
Process record: failed to record execution log.
[Thread 0x7ffff7fe3700 (LWP 26985)] #1 stopped.
memset () at ../sysdeps/x86_64/memset.S:746
746		 movd   %rdx,%xmm0
(gdb) 

kernel-2.6.32.1-9.fc13.x86_64 -> x86_64 gdb -> i386 inferior:
(gdb) start
Temporary breakpoint 1 at 0x80484f4: file /home/jkratoch/t/threadit.c, line 40.
Starting program: /home/jkratoch/t/threadit32 
warning: .dynamic section for "/lib/libc.so.6" is not at the expected address
warning: difference appears to be caused by prelink, adjusting expectations
[Thread debugging using libthread_db enabled]
Temporary breakpoint 1, main () at /home/jkratoch/t/threadit.c:40
40	  i = pthread_create (&thread1, NULL, start, NULL);	/* create1 */
(gdb) record 
(gdb) c
Continuing.
warning: Process record ignores the memory change of instruction at address 0x18a7c5 because it can't get the value of the segment register.
Cannot find user-level thread for LWP 11809: generic error
(/lib/libpthread-2.11.so has been prelinked to avoid some existing bug)

kernel-2.6.32.1-9.fc13.x86_64 -> i386 gdb -> i386 inferior:
(gdb) start
Temporary breakpoint 1 at 0x80484f4: file /home/jkratoch/t/threadit.c, line 40.
Starting program: /home/jkratoch/t/threadit32 
[Thread debugging using libthread_db enabled]
Temporary breakpoint 1, main () at /home/jkratoch/t/threadit.c:40
40	  i = pthread_create (&thread1, NULL, start, NULL);	/* create1 */
(gdb) record 
(gdb) c
Continuing.
warning: Process record ignores the memory change of instruction at address 0x3557c5 because it can't get the value of the segment register.
Program terminated with signal SIGTRAP, Trace/breakpoint trap.
The program no longer exists.
(gdb) 



[-- Attachment #2: threadit.c --]
[-- Type: text/plain, Size: 341 bytes --]

#include <pthread.h>
#include <assert.h>
#include <unistd.h>

static volatile int var;

static void *start (void *arg)
{
  sleep (1);
  return arg;
}

int main (void)
{
  pthread_t thread1;
  int i;

  i = pthread_create (&thread1, NULL, start, NULL);
  assert (i == 0);
  i = pthread_join (thread1, NULL);
  assert (i == 0);

  return 0;
}

Re: Reverse Debugging Headaches

[Sean Soria]

Are there instructions or advice to accompany this?

On Mon, Jan 11, 2010 at 12:54 PM, Jan Kratochvil
<jan.kratochvil@redhat.com> wrote:
> On Mon, 11 Jan 2010 19:47:13 +0100, Michael Snyder wrote:
>> Sean Soria wrote:
>> >Whenever I try to reverse debug I break into the program, set target
>> >record and then continue. I immediately hit some sort of simd
>> >instruction (in things like strlen in libc) or unsupported ioctl call.
>> > Is there any way around these issues?
>>
>> Shouldn't happen.  What version gdb?  What linux?
>
> gdb 7.0.50.20100111-cvs Fedora 12:
>
> kernel-2.6.32.1-9.fc13.x86_64 -> x86_64 gdb -> x86_64 inferior:
> (gdb) start
> Temporary breakpoint 1 at 0x400640: file threadit.c, line 40.
> Starting program: /home/jkratoch/t/threadit
> [Thread debugging using libthread_db enabled]
> Temporary breakpoint 1, main () at threadit.c:40
> 40        i = pthread_create (&thread1, NULL, start, NULL);     /* create1 */
> (gdb) record
> (gdb) c
> Continuing.
> warning: Process record ignores the memory change of instruction at address 0x362de0db46 because it can't get the value of the segment register.
> [...]
> warning: Process record ignores the memory change of instruction at address 0x362e274d46 because it can't get the value of the segment register.
> Process record doesn't support instruction 0xf6e at address 0x362e281a32.
> Process record: failed to record execution log.
> [Thread 0x7ffff7fe3700 (LWP 26985)] #1 stopped.
> memset () at ../sysdeps/x86_64/memset.S:746
> 746              movd   %rdx,%xmm0
> (gdb)
>
> kernel-2.6.32.1-9.fc13.x86_64 -> x86_64 gdb -> i386 inferior:
> (gdb) start
> Temporary breakpoint 1 at 0x80484f4: file /home/jkratoch/t/threadit.c, line 40.
> Starting program: /home/jkratoch/t/threadit32
> warning: .dynamic section for "/lib/libc.so.6" is not at the expected address
> warning: difference appears to be caused by prelink, adjusting expectations
> [Thread debugging using libthread_db enabled]
> Temporary breakpoint 1, main () at /home/jkratoch/t/threadit.c:40
> 40        i = pthread_create (&thread1, NULL, start, NULL);     /* create1 */
> (gdb) record
> (gdb) c
> Continuing.
> warning: Process record ignores the memory change of instruction at address 0x18a7c5 because it can't get the value of the segment register.
> Cannot find user-level thread for LWP 11809: generic error
> (/lib/libpthread-2.11.so has been prelinked to avoid some existing bug)
>
> kernel-2.6.32.1-9.fc13.x86_64 -> i386 gdb -> i386 inferior:
> (gdb) start
> Temporary breakpoint 1 at 0x80484f4: file /home/jkratoch/t/threadit.c, line 40.
> Starting program: /home/jkratoch/t/threadit32
> [Thread debugging using libthread_db enabled]
> Temporary breakpoint 1, main () at /home/jkratoch/t/threadit.c:40
> 40        i = pthread_create (&thread1, NULL, start, NULL);     /* create1 */
> (gdb) record
> (gdb) c
> Continuing.
> warning: Process record ignores the memory change of instruction at address 0x3557c5 because it can't get the value of the segment register.
> Program terminated with signal SIGTRAP, Trace/breakpoint trap.
> The program no longer exists.
> (gdb)
>
>
>
> #include <pthread.h>
> #include <assert.h>
> #include <unistd.h>
>
> static volatile int var;
>
> static void *start (void *arg)
> {
>  sleep (1);
>  return arg;
> }
>
> int main (void)
> {
>  pthread_t thread1;
>  int i;
>
>  i = pthread_create (&thread1, NULL, start, NULL);
>  assert (i == 0);
>  i = pthread_join (thread1, NULL);
>  assert (i == 0);
>
>  return 0;
> }
>
>

Re: Reverse Debugging Headaches

[Hui Zhu]

Hello,

The prec in cvs-head still doesn't support multi-thread inferior.
We just have a series of patches to make prec support multi-thread
inferior. You can get the link for it in
http://sourceware.org/gdb/wiki/ProcessRecord

BTW it didn't update follow gdb-cvs-head.   Mail me if you need it, I
will update it.

Thanks,
Hui

On Tue, Jan 12, 2010 at 04:57, Sean Soria <sean.soria@gmail.com> wrote:
> Are there instructions or advice to accompany this?
>
> On Mon, Jan 11, 2010 at 12:54 PM, Jan Kratochvil
> <jan.kratochvil@redhat.com> wrote:
>> On Mon, 11 Jan 2010 19:47:13 +0100, Michael Snyder wrote:
>>> Sean Soria wrote:
>>> >Whenever I try to reverse debug I break into the program, set target
>>> >record and then continue. I immediately hit some sort of simd
>>> >instruction (in things like strlen in libc) or unsupported ioctl call.
>>> > Is there any way around these issues?
>>>
>>> Shouldn't happen.  What version gdb?  What linux?
>>
>> gdb 7.0.50.20100111-cvs Fedora 12:
>>
>> kernel-2.6.32.1-9.fc13.x86_64 -> x86_64 gdb -> x86_64 inferior:
>> (gdb) start
>> Temporary breakpoint 1 at 0x400640: file threadit.c, line 40.
>> Starting program: /home/jkratoch/t/threadit
>> [Thread debugging using libthread_db enabled]
>> Temporary breakpoint 1, main () at threadit.c:40
>> 40        i = pthread_create (&thread1, NULL, start, NULL);     /* create1 */
>> (gdb) record
>> (gdb) c
>> Continuing.
>> warning: Process record ignores the memory change of instruction at address 0x362de0db46 because it can't get the value of the segment register.
>> [...]
>> warning: Process record ignores the memory change of instruction at address 0x362e274d46 because it can't get the value of the segment register.
>> Process record doesn't support instruction 0xf6e at address 0x362e281a32.
>> Process record: failed to record execution log.
>> [Thread 0x7ffff7fe3700 (LWP 26985)] #1 stopped.
>> memset () at ../sysdeps/x86_64/memset.S:746
>> 746              movd   %rdx,%xmm0
>> (gdb)
>>
>> kernel-2.6.32.1-9.fc13.x86_64 -> x86_64 gdb -> i386 inferior:
>> (gdb) start
>> Temporary breakpoint 1 at 0x80484f4: file /home/jkratoch/t/threadit.c, line 40.
>> Starting program: /home/jkratoch/t/threadit32
>> warning: .dynamic section for "/lib/libc.so.6" is not at the expected address
>> warning: difference appears to be caused by prelink, adjusting expectations
>> [Thread debugging using libthread_db enabled]
>> Temporary breakpoint 1, main () at /home/jkratoch/t/threadit.c:40
>> 40        i = pthread_create (&thread1, NULL, start, NULL);     /* create1 */
>> (gdb) record
>> (gdb) c
>> Continuing.
>> warning: Process record ignores the memory change of instruction at address 0x18a7c5 because it can't get the value of the segment register.
>> Cannot find user-level thread for LWP 11809: generic error
>> (/lib/libpthread-2.11.so has been prelinked to avoid some existing bug)
>>
>> kernel-2.6.32.1-9.fc13.x86_64 -> i386 gdb -> i386 inferior:
>> (gdb) start
>> Temporary breakpoint 1 at 0x80484f4: file /home/jkratoch/t/threadit.c, line 40.
>> Starting program: /home/jkratoch/t/threadit32
>> [Thread debugging using libthread_db enabled]
>> Temporary breakpoint 1, main () at /home/jkratoch/t/threadit.c:40
>> 40        i = pthread_create (&thread1, NULL, start, NULL);     /* create1 */
>> (gdb) record
>> (gdb) c
>> Continuing.
>> warning: Process record ignores the memory change of instruction at address 0x3557c5 because it can't get the value of the segment register.
>> Program terminated with signal SIGTRAP, Trace/breakpoint trap.
>> The program no longer exists.
>> (gdb)
>>
>>
>>
>> #include <pthread.h>
>> #include <assert.h>
>> #include <unistd.h>
>>
>> static volatile int var;
>>
>> static void *start (void *arg)
>> {
>>  sleep (1);
>>  return arg;
>> }
>>
>> int main (void)
>> {
>>  pthread_t thread1;
>>  int i;
>>
>>  i = pthread_create (&thread1, NULL, start, NULL);
>>  assert (i == 0);
>>  i = pthread_join (thread1, NULL);
>>  assert (i == 0);
>>
>>  return 0;
>> }
>>
>>
>

Re: Reverse Debugging Headaches

[Jan Kratochvil]

Hi Hui,

On Wed, 13 Jan 2010 10:28:47 +0100, Hui Zhu wrote:
> The prec in cvs-head still doesn't support multi-thread inferior.
> We just have a series of patches to make prec support multi-thread
> inferior. You can get the link for it in
> http://sourceware.org/gdb/wiki/ProcessRecord

ok, sorry I have not tracked it.

Wouldn't you prefer to maintain the off-trunk patches in public Archer GIT?
	http://sourceware.org/gdb/wiki/ArcherBranchManagement
Or making your own GIT public with some merged branch there.
You are apparently already developing it in GIT yourself.
Please ignore me if it was already discussed before.


Thanks,
Jan

Re: Reverse Debugging Headaches

[Hui Zhu]

I don't have myself git.  My patch looks like get from git because I
generate patch with quilt.  :)

I will try to make mthread support patch check-in in recent days.

For archer, thanks a lot of told me about it.  If I have a lot of
off-trunk patch, I will try to use it.

Best regards,
Hui

On Wed, Jan 13, 2010 at 19:11, Jan Kratochvil <jan.kratochvil@redhat.com> wrote:
> Hi Hui,
>
> On Wed, 13 Jan 2010 10:28:47 +0100, Hui Zhu wrote:
>> The prec in cvs-head still doesn't support multi-thread inferior.
>> We just have a series of patches to make prec support multi-thread
>> inferior. You can get the link for it in
>> http://sourceware.org/gdb/wiki/ProcessRecord
>
> ok, sorry I have not tracked it.
>
> Wouldn't you prefer to maintain the off-trunk patches in public Archer GIT?
>        http://sourceware.org/gdb/wiki/ArcherBranchManagement
> Or making your own GIT public with some merged branch there.
> You are apparently already developing it in GIT yourself.
> Please ignore me if it was already discussed before.
>
>
> Thanks,
> Jan
>

Re: Reverse Debugging Headaches

[Michael Snyder]

Hui Zhu wrote:

> I will try to make mthread support patch check-in in recent days.

We'll want to see some tests...   ;-)

Re: Reverse Debugging Headaches

[Hui Zhu]

I am working on it.  :)

Hui

On Fri, Jan 15, 2010 at 03:00, Michael Snyder <msnyder@vmware.com> wrote:
> Hui Zhu wrote:
>
>> I will try to make mthread support patch check-in in recent days.
>
> We'll want to see some tests...   ;-)
>