Hi -
On Thu, Sep 23, 2010 at 02:21:38PM -0700, Roland McGrath wrote:
> > > The ones I'm talking about are Z2/Z3 for (data) watchpoints.
> > Ah, OK, thanks. I'll try to understand how this works.
>
> In theory these will map to uses of the hw_breakpoint interface.
Not quite. The hw_breakpoint wi
> 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 performance-related.
My vague notion was that we'd ge
> > The ones I'm talking about are Z2/Z3 for (data) watchpoints.
>
> Ah, OK, thanks. I'll try to understand how this works.
In theory these will map to uses of the hw_breakpoint interface.
Thanks,
Roland
On 09/22, Frank Ch. Eigler wrote:
>
> On Thu, Sep 23, 2010 at 01:14:51AM +0200, Oleg Nesterov wrote:
> >
> > When I do 'watch', gdb sends '$Z2'. I am a bit confused, iirc it
> > was decided I shouldn't play with Z packets now. But I won't
> > argue.
>
> There are Z packets and then there are Z pack
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/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 s
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 u
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
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
gdb+gd
