But. Suppose we have to attached engines. The first engine gets
UTRACE_SIGNAL_REPORT and returns UTRACE_STOP | UTRACE_SIGNAL_IGN.
Right, that's what it would do. I see, you're saying that the
report.result passed on to the next engine would appear like it had
been a real signal that the
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
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/06, Frank Ch. Eigler wrote:
Oleg Nesterov o...@redhat.com writes:
[...]
Therefore until you track some ugdb-specific software(*)
breakpoints ugdb does not need to support Z0 IMO. I guess ugdb
will never have to support these: thread-related(?) and tracepoint
ones.
Good! I
On 09/05, Jan Kratochvil wrote:
On Sat, 04 Sep 2010 00:40:47 +0200, Oleg Nesterov wrote:
- implement qXfer:siginfo:read
- implement continue with signal.
OK, thanks, just it was a bit premature to ask for it I see. I miss at least
memory writes
Yes. This is simple.
(also to
On 09/06, Jan Kratochvil wrote:
On Mon, 06 Sep 2010 20:18:08 +0200, Oleg Nesterov wrote:
On 09/05, Jan Kratochvil wrote:
(also to put in breakpoints):
And this is not clear to me, I need your help ;)
Sorry, I just meant that by implementing the memory writes breakpoints
