Please note that last year's gdbstub prototype used kernel uprobes as
an optional gdb breakpoint implementation (i.e., a backend for the Z
packets). When/if the lkml uprobes patches actually get merged, ugdb
should also use them.
That's something for later, and it's not quite so simple. If
I am a bit confused... OK, ugdb is wrong wrt multitracing.
UTRACE_SIGNAL_REPORT case shouldn't return UTRACE_STOP | UTRACE_SIGNAL_IGN,
it should return UTRACE_STOP | UTRACE_SIGNAL_REPORT to keep report-result.
No, UTRACE_SIGNAL_REPORT is not meant for a return value. Its only use is
in the
But I meant another case, when the stopped tracee doesn't have siginfo.
Currently ugdb just sends this signal to tracee, and then it will be
reported to gdb. Not sure if this is right or not, I can change this.
(or perhap this doesn't matter, I dunno).
What do you mean by doesn't have
I misunderstood the UTRACE_INTERRUPT without UTRACE_EVENT(QUIESCE) above
as if you mean it is possible to get UTRACE_SIGNAL_REPORT without QUIESCE.
No, I meant the opposite: since you won't get UTRACE_SIGNAL_REPORT without
UTRACE_EVENT(QUIESCE), it might seem that UTRACE_INTERRUPT should not be
On 09/10, Roland McGrath wrote:
Oleg == Oleg Nesterov o...@redhat.com writes:
Oleg (gdb) set var 0
You need: set variable var = 0
The variable can be abbreviated.
I've always just used:
(gdb) set var=0
No, I tried this too, doesn't work.
(gdb) set var=0
On 09/10, Roland McGrath wrote:
But I meant another case, when the stopped tracee doesn't have siginfo.
Currently ugdb just sends this signal to tracee, and then it will be
reported to gdb. Not sure if this is right or not, I can change this.
(or perhap this doesn't matter, I dunno).
ugdb sets please stop flag and does utrace_control(INTERRUPT). However,
in unlikely case the tracee can stop before -report_signal() reporting
I don't think this is the right thing to do. When the intent is explicitly
to interrupt, there is no reason to stop before the interruption is
On 09/10, Roland McGrath wrote:
I am a bit confused... OK, ugdb is wrong wrt multitracing.
UTRACE_SIGNAL_REPORT case shouldn't return UTRACE_STOP |
UTRACE_SIGNAL_IGN,
it should return UTRACE_STOP | UTRACE_SIGNAL_REPORT to keep
report-result.
No, UTRACE_SIGNAL_REPORT is not meant for
On 09/10, Roland McGrath wrote:
ugdb sets please stop flag and does utrace_control(INTERRUPT). However,
in unlikely case the tracee can stop before -report_signal() reporting
I don't think this is the right thing to do. When the intent is explicitly
to interrupt, there is no reason to
Oleg == Oleg Nesterov o...@redhat.com writes:
I've always just used:
(gdb) set var=0
Oleg No, I tried this too, doesn't work.
Oleg (gdb) set var=0
Oleg A syntax error in expression, near `=0'.
Yeah, it is ambiguous if the actual variable name conflicts with any gdb
set subcommand.
I
Oleg Now, to continue the tracee, gdb does not restore the
Oleg original instruction. Instead, it
Oleg - writes this insn into _start code
Oleg - changes regs-ip to point to this insn
Oleg - does single-step to execute this insn
Oleg - changes regs-ip
11 matches
Mail list logo
