On 10/13, Roland McGrath wrote:
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
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
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:
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
On Thu, 02 Sep 2010 22:06:32 +0200, Oleg Nesterov wrote:
I assume that qXfer:siginfo:read always mean Hg thread.
It seems so.
It is not clear to me what should ugdb report if there is no a valid
siginfo. linux_xfer_siginfo() return E01, but gdbserver uses SIGSTOP to
stop the tracee,
I find
Oleg Nesterov o...@redhat.com writes:
[...] To the point, I had to add printk's to utrace.c to understand
what is wrong. Hopefully tomorrow.
You might wish to try out systemtap for such purposes. It's easy to
insert printk-like tracing at almost any point; monitor variables for
changes,
Currently GDB does not do anything special, that is if there is siginfo for
signal SIGUSR1 but one does $C0B (SIGSEGV) does ptrace reset the siginfo or is
left the SIGUSR1 siginfo for SIGSEGV?
The kernel considers this sloppy behavior on the debugger's part. If
you inject a different signal,
On Fri, 03 Sep 2010 21:59:06 +0200, Roland McGrath wrote:
Currently GDB does not do anything special, that is if there is siginfo for
signal SIGUSR1 but one does $C0B (SIGSEGV) does ptrace reset the siginfo or
is
left the SIGUSR1 siginfo for SIGSEGV?
The kernel considers this sloppy
Sorry for the delay, I was distracted. Trying to switch back to ugdb.
On 08/31, Jan Kratochvil wrote:
ugdb should support qXfer:siginfo, currently accessible only via $_siginfo
print/set, though.
Still sure this feature should be also implemented one day.
Yes sure. This should be simple,
On Mon, 30 Aug 2010 21:20:40 +0200, Jan Kratochvil wrote:
On Mon, 30 Aug 2010 20:58:50 +0200, Oleg Nesterov wrote:
- report signals. A bit more code changes than I expected.
BTW not sure if it is already the right time for it but to keep ugdb on-par
with my linux-nat's re-post today
On Mon, 30 Aug 2010 20:58:50 +0200, Oleg Nesterov wrote:
- report signals. A bit more code changes than I expected.
BTW not sure if it is already the right time for it but to keep ugdb on-par
with my linux-nat's re-post today (still not accepted in FSF GDB)
[0/9]#2 Fix lost
12 matches
Mail list logo
