Oleg But what about features? What should I do next? all-stop,
Oleg thread-specific breakpoints (currently I have no idea what
Oleg this means), or what?
I think it would be good to implement a feature that shows how this
approach is an improvement over the current state of gdb+ptrace or
On Wed, 22 Sep 2010 21:09:12 +0200, Tom Tromey wrote:
I think it would be good to implement a feature that shows how this
approach is an improvement over the current state of gdb+ptrace or
gdb+gdbserver.
Exactly what feature this should be... I don't know :-)
I would imagine something
On 09/22, Frank Ch. Eigler wrote:
oleg wrote:
[...] Honestly, I don't really know how do the right thing here.
Anyway, most probably this code will be changed. Like ptrace, ugdb
uses -report_syscall_exit() to synthesize a trap. Unlike ptrace,
ugdb_report_signal() doesn't send SIGTRAP
Hi -
On Thu, Sep 23, 2010 at 01:14:51AM +0200, Oleg Nesterov wrote:
(It seems to me that a pure gdb report, without a synthetic
self-injected SIGTRAP, should be fine.)
What do you mean?
(Never mind, I'm probably just confused about what you were asking.)
Next: fully implement
On 09/21, Roland McGrath wrote:
OK, so what should we do for now?
If we can't come to a straightforward answer for the general case
fairly quickly, then we can do the simple change to start with.
I think we should start with changing utrace_control(DETACH) anyway,
then try to improve. I'll
On 09/23, Oleg Nesterov wrote:
On 09/21, Roland McGrath wrote:
It's better to have a spurious report (preferably just spurious
TIF_NOTIFY_RESUME with no actual callbacks) following any detach,
or whatever it takes to ensure user_disable_single_step() always
runs if user_enable_*_step
