I think this is a hehavior of kernel. I think change pc always a danger thing. :)
infrun: clear_proceed_status_thread (process 4542) 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) infrun: target_wait (-1, status) = infrun: 4542 [process 4542], infrun: status->kind = stopped, signal = SIGINT infrun: infwait_normal_state infrun: TARGET_WAITKIND_STOPPED infrun: stop_pc = 0xb7fe3410 infrun: random signal 2 Program received signal SIGINT, Interrupt. infrun: stop_stepping 0xb7fe3410 in __kernel_vsyscall () (gdb) disas Dump of assembler code for function __kernel_vsyscall: 0xb7fe3400 <+0>: push %ecx 0xb7fe3401 <+1>: push %edx 0xb7fe3402 <+2>: push %ebp 0xb7fe3403 <+3>: mov %esp,%ebp 0xb7fe3405 <+5>: sysenter 0xb7fe3407 <+7>: nop 0xb7fe3408 <+8>: nop 0xb7fe3409 <+9>: nop 0xb7fe340a <+10>: nop 0xb7fe340b <+11>: nop 0xb7fe340c <+12>: nop 0xb7fe340d <+13>: nop 0xb7fe340e <+14>: jmp 0xb7fe3403 <__kernel_vsyscall+3> => 0xb7fe3410 <+16>: pop %ebp 0xb7fe3411 <+17>: pop %edx 0xb7fe3412 <+18>: pop %ecx 0xb7fe3413 <+19>: ret End of assembler dump. (gdb) p $pc $1 = (void (*)()) 0xb7fe3410 <__kernel_vsyscall+16> (gdb) p $pc=0xb7fe3413 $2 = (void (*)()) 0xb7fe3413 <__kernel_vsyscall+19> (gdb) si infrun: clear_proceed_status_thread (process 4542) infrun: proceed (addr=0xffffffff, signal=144, step=1) infrun: resume (step=1, signal=0), trap_expected=0 infrun: wait_for_inferior (treat_exec_as_sigtrap=0) infrun: target_wait (-1, status) = infrun: 4542 [process 4542], infrun: status->kind = stopped, signal = SIGTRAP infrun: infwait_normal_state infrun: TARGET_WAITKIND_STOPPED infrun: stop_pc = 0xb7fe3412 infrun: stepi/nexti infrun: stop_stepping 0xb7fe3412 in __kernel_vsyscall () Thanks, Hui On Nov 2, 7:27 pm, Alexandre Rusev <[email protected]> wrote: > teawater wrote: > > This signal ctrl-c will not really send to inferior. > > But the result is interrupted system call which is restarted then by kernel. > And is user changes program counter in GDB at this point, > then it takes place before the modification of PC is done by kernel. > The result is that execution jumps neither to the point the user said in > GDB nor > to the point the kernel wishes it be due to restart the syscall. > > Is it incorrect behavior of GDB or incorrect behavior of kernel or > something else??? > > > (gdb) help info handle > > > On Oct 31, 12:10 am, Alexandre Rusev <[email protected]> wrote: > > >> Hi. > > >> When the program at ht end of message debugged under GDB is stopped with > >> Ctrl+C > >> it's usually found in interrupted system call. (The same result is > >> observed for x86 and PPC with kernels 2.6.18 and 2.6.28) > > >> (gdb) where > >> #0 0xb7fe2424 in __kernel_vsyscall () > >> #1 0xb7f36ad0 in nanosleep () from /lib/libc.so.6 > >> #2 0xb7f3690e in sleep () from /lib/libc.so.6 > >> #3 0x08048600 in qqq () at testBT2.c:45 > >> #4 0x080487a5 in eee () at testBT2.c:73 > >> #5 0x0804846a in main () at testBT2.c:17 > > >> The PC is pointing at the next instruction, accordingly to GDB. > >> But the kernel tries to restart syscall by means of changing PC to PC-4 > >> (in case of PowerPC and to some other value for x86) > >> and it does it's change to PC after the user continues execution of > >> program in GDB with "cont" or "si" command. > > >> The issue is that if user changed PC at this point or uses "call > >> <func_name>" GDB command, the both changes to PC > >> are added (as kernel uses PC relative change i.e. PC - 4), and the > >> program continues execution at absolutely wrong place. > > >> The issue may be gracefully observed if breakpoint is set just before > >> <func_name> and then PC is changed to the <func_name> address. > >> In such case the breakpoint is hit while it must not be. > > >> #include <stdio.h> > >> #include <stdlib.h> > > >> void qqq(); > >> void www(); > >> void eee(); > > >> void * xrealloc(void*, int); > > >> int main(void) > >> { > >> eee(); > >> return EXIT_SUCCESS; > > >> } > > >> void qqq() { > >> void *a[256]; > >> size_t i, n; > > >> for (i = 0; i < 256; i++) > >> { > >> n = (size_t) ((rand() * 256.0) / (RAND_MAX + 1.0)) + 1; > >> a[i] = malloc(n); > >> } > >> for (i = 256; i > 0; i--) > >> { > >> n = (size_t) ((rand() * 256.0) / (RAND_MAX + 1.0)) + 1; > >> a[i - 1] = xrealloc(a[i - 1], n); > >> } > >> sleep(1); > >> for (i = 0; i < 256; i += 2) > >> free(a[i]); > >> for (i = 256; i > 0; i -= 2) > >> free(a[i - 1]); > >> sleep(1); > > >> } > > >> void www() { > >> void *a[256]; > >> size_t i, n; > > >> for (i = 0; i < 256; i++) > >> { > >> n = (size_t) ((rand() * 256.0) / (RAND_MAX + 1.0)) + 1; > >> a[i] = malloc(n); > >> } > >> for (i = 256; i > 0; i--) > >> { > >> n = (size_t) ((rand() * 256.0) / (RAND_MAX + 1.0)) + 1; > >> a[i - 1] = realloc(a[i - 1], n); > >> } > >> sleep(1); > >> for (i = 0; i < 256; i += 2) > >> free(a[i]); > >> for (i = 256; i > 0; i -= 2) > >> free(a[i - 1]); > >> sleep(1); > > >> } > > >> void eee() { > > >> while (1) { > >> qqq(); > > >> www(); > > >> } > > >> } > > >> void * xrealloc(void* addr, int n) { > >> return realloc(addr, n); > > >> } > > > _______________________________________________ > > bug-gdb mailing list > > [email protected] > >http://lists.gnu.org/mailman/listinfo/bug-gdb _______________________________________________ bug-gdb mailing list [email protected] http://lists.gnu.org/mailman/listinfo/bug-gdb
