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 to itself but reports > SIGTRAP using siginfo_t we have. In any case, whatever we do, > multiple tracers can confuse each other.
(It seems to me that a pure gdb report, without a synthetic self-injected SIGTRAP, should be fine.) > Next: fully implement g/G/p/P, currently I am a bit confused... > But what about features? [...] You could dig out the old "fishing plan". One demonstrated improvement was from simulating (software) watchpoints within the gdb stub, instead of having gdb fall back to issing countless single-steps with memory-fetch inquiries in between. - FChE
