Sorry. I cannot agree with it.
It make GDB not flexible.
Hui
On Fri, Nov 13, 2009 at 22:42, Alexandre Rusev aru...@ru.mvista.com wrote:
teawater wrote:
I think this is a hehavior of kernel. I think change pc always a
danger thing. :)
Yes, extremely dangeorous! ;)
But GDB supports
teawater wrote:
I think this is a hehavior of kernel. I think change pc always a
danger thing. :)
Yes, extremely dangeorous! ;)
But GDB supports feature such as call func_name, when using it the
Joe user does not even cares the PC,
he just thinks that he makes call to some function...
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=0x, signal=144, step=0)
infrun: resume (step=0, signal=0), trap_expected=0
infrun: wait_for_inferior (treat_exec_as_sigtrap=0)
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
This signal ctrl-c will not really send to inferior.
(gdb) help info handle
On Oct 31, 12:10 am, Alexandre Rusev aru...@ru.mvista.com 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
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
