Re: [RFA] Fix hw watchpoints in process record.

[Hui Zhu <teawater at gmail dot com>]

My os is ubuntu 8.0.4 i386 gcc version 4.2.4.

The following is a simple hw in my pc:
Temporary breakpoint 1, main () at 1.c:20
20	       int     b = 0;
(gdb) hb 31
During symbol reading, incomplete CFI data; unspecified registers
(e.g., eax) at 0x80483be.
Hardware assisted breakpoint 2 at 0x8048447: file 1.c, line 31.
(gdb) set debug infrun 1
(gdb) c
Continuing.
infrun: clear_proceed_status_thread (process 20269)
infrun: proceed (addr=0xffffffff, signal=144, step=0)
infrun: resume (step=0, signal=0), trap_expected=0
infrun: wait_for_inferior (treat_exec_as_sigtrap=0)
a = 0 b = 0 c = 1
a = 3
a = 3 b = 3 c = 1
a = 3 b = 3 c = 2
infrun: target_wait (-1, status) =
infrun:   20269 [process 20269],
infrun:   status->kind = stopped, signal = SIGTRAP
infrun: infwait_normal_state
infrun: TARGET_WAITKIND_STOPPED
infrun: stop_pc = 0x8048447
infrun: BPSTAT_WHAT_STOP_NOISY
infrun: stop_stepping

Breakpoint 2, main () at 1.c:31
31	       a -= 2;


The following is the hw with prec:
Temporary breakpoint 1, main () at 1.c:20
20	       int     b = 0;
(gdb) record
(gdb) set debug infrun 1
(gdb) hb 31
During symbol reading, incomplete CFI data; unspecified registers
(e.g., eax) at 0x80483be.
Hardware assisted breakpoint 2 at 0x8048447: file 1.c, line 31.
(gdb) c
Continuing.
infrun: clear_proceed_status_thread (process 1842)
infrun: proceed (addr=0xffffffff, signal=144, step=0)
infrun: resume (step=0, signal=0), trap_expected=0
infrun: wait_for_inferior (treat_exec_as_sigtrap=0)
a = 0 b = 0 c = 1
a = 3
a = 3 b = 3 c = 1
a = 3 b = 3 c = 2
infrun: target_wait (-1, status) =
infrun:   1842 [process 1842],
infrun:   status->kind = stopped, signal = SIGTRAP
infrun: infwait_normal_state
infrun: TARGET_WAITKIND_STOPPED
infrun: stop_pc = 0x8048448
infrun: random signal 5

Program received signal SIGTRAP, Trace/breakpoint trap.
infrun: stop_stepping
0x08048448 in main () at 1.c:31
31	       a -= 2;


Looks like the stop_pc is not right.

Thanks,
Hui


On Tue, Nov 10, 2009 at 05:19, Michael Snyder <msnyder@vmware.com> wrote:
> Hui Zhu wrote:
>>
>> Still not very well, with the old program:
>>
>> (gdb) start
>> Temporary breakpoint 1 at 0x80483c1: file 1.c, line 20.
>> Starting program: /home/teawater/gdb/a.out
>> warning: the debug information found in "/lib/ld-2.7.so" does not
>> match "/lib/ld-linux.so.2" (CRC mismatch).
>>
>> warning: the debug information found in
>> "/lib/tls/i686/cmov/libc-2.7.so" does not match
>> "/lib/tls/i686/cmov/libc.so.6" (CRC mismatch).
>>
>>
>> Temporary breakpoint 1, main () at 1.c:20
>> 20 ? ? ? ? ? ? int ? ? b = 0;
>> (gdb) record
>> (gdb) n
>> During symbol reading, incomplete CFI data; unspecified registers
>> (e.g., eax) at 0x80483be.
>> 21 ? ? ? ? ? ? int ? ? c = 1;
>> (gdb)
>> 24 ? ? ? ? ? ? ?printf ("a = %d b = %d c = %d\n", a, b, c);
>> (gdb) hw
>> Undefined command: "hw". ?Try "help".
>> (gdb) hb
>> Hardware assisted breakpoint 2 at 0x80483cf: file 1.c, line 24.
>> (gdb) c
>> Continuing.
>> a = 0 b = 0 c = 1
>> a = 3
>> a = 3 b = 3 c = 1
>> a = 3 b = 3 c = 2
>> a = 1 b = 3 c = 2
>> The next instruction is syscall exit_group. ?It will make the program
>> exit. ?Do you want to stop the program?([y] or n)
>> Process record: inferior program stopped.
>>
>> Program received signal SIGTRAP, Trace/breakpoint trap.
>> 0xb7fe3405 in __kernel_vsyscall ()
>> (gdb) rc
>> Continuing.
>>
>> Breakpoint 2, main () at 1.c:24
>> 24 ? ? ? ? ? ? ?printf ("a = %d b = %d c = %d\n", a, b, c);
>> (gdb) rc
>> Continuing.
>>
>> No more reverse-execution history.
>> main () at 1.c:20
>> 20 ? ? ? ? ? ? int ? ? b = 0;
>> (gdb) c
>> Continuing.
>>
>> Program received signal SIGTRAP, Trace/breakpoint trap.
>> 0x080483d0 in main () at 1.c:24
>> 24 ? ? ? ? ? ? ?printf ("a = %d b = %d c = %d\n", a, b, c);
>> (gdb) c
>> Continuing.
>>
>> No more reverse-execution history.
>> 0xb7fe3405 in __kernel_vsyscall ()
>> (gdb) rc
>> Continuing.
>>
>> No more reverse-execution history.
>> main () at 1.c:20
>> 20 ? ? ? ? ? ? int ? ? b = 0;
>> (gdb) c
>> Continuing.
>>
>> No more reverse-execution history.
>> 0xb7fe3405 in __kernel_vsyscall ()
>> (gdb) rc
>> Continuing.
>>
>> No more reverse-execution history.
>> main () at 1.c:20
>> 20 ? ? ? ? ? ? int ? ? b = 0;
>> (gdb) info b
>> Num ? ? Type ? ? ? ? ? Disp Enb Address ? ?What
>> 2 ? ? ? hw breakpoint ?keep y ? 0x080483cf in main at 1.c:24
>> ? ? ? ?breakpoint already hit 1 time
>> (gdb) c
>> Continuing.
>>
>> No more reverse-execution history.
>> 0xb7fe3405 in __kernel_vsyscall ()
>>
>>
>> Thanks,
>> Hui
>
> That's odd, I don't get anything like that.
> It basically works correctly for me, except for
> an unrelated bug that I'm currently looking into.
>
> I'm using RHEL4 and gcc (GCC) 3.4.6 20060404 (Red Hat 3.4.6-11)
>
>
>