gdbstub initial code, v11

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+gdbserver.

Exactly what feature this should be... I don't know :-)
I would imagine something performance-related.

There was previously some discussion about some watchpoint-related
thing, I forget the details of that.

I don't think thread-specific breakpoints are exposed outside of gdb
yet. If that is true, then implementing that would mean adding remote
protocol features and also other stuff inside gdb. So, I would suggest
not tackling this yet.

Tom

Jan Kratochvil

2010-09-22 19:18:37 UTC

Post by Tom Tromey
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.

I would bet on a massive threads creating/deleting testcase signalling tasks
around, together with watchpoints. There are races in the linux-nat code and
IIRC even gdbserver code.

OTOH if one tries hard one can probably manage one day to fix all the corner
cases in the ptrace based linux-nat and gdbserver.

Regards,
Jan

Roland McGrath

2010-09-23 21:24:23 UTC

My vague notion was that we'd get it working well enough to have basic
parity with native or gdbserver on some realish test cases, and then just
look at the protocol interaction log to see cases where we could reduce
round-trips between gdb and the stub. Some of those are bound to entail
protocol extensions and gdb changes to exploit them. Off hand, the Z cases
might be the only things that won't need that.

Thanks,
Roland

Frank Ch. Eigler

2010-09-22 22:06:05 UTC

[...] 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

Oleg Nesterov

2010-09-22 23:14:51 UTC

(It seems to me that a pure gdb report, without a synthetic
self-injected SIGTRAP, should be fine.)

What do you mean?

Next: fully implement g/G/p/P, currently I am a bit confused...
But what about features? [...]

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.

Oleg.

Frank Ch. Eigler

2010-09-22 23:39:09 UTC

Hi -

Post by Frank Ch. Eigler
(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.)

Post by Oleg Nesterov
Next: fully implement g/G/p/P, currently I am a bit confused...
But what about features? [...]

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 packets. The ones Roland
told you not to worry about are Z0/Z1 related to (code) breakpoints,
which should be implemented via uprobes at some point.

The ones I'm talking about are Z2/Z3 for (data) watchpoints.

- FChE

Oleg Nesterov

2010-09-22 23:44:43 UTC

Post by Oleg Nesterov
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 packets. The ones Roland
told you not to worry about are Z0/Z1 related to (code) breakpoints,
which should be implemented via uprobes at some point.
The ones I'm talking about are Z2/Z3 for (data) watchpoints.

Ah, OK, thanks. I'll try to understand how this works.

Oleg.

Roland McGrath

2010-09-23 21:21:38 UTC

Post by Frank Ch. Eigler
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

Frank Ch. Eigler

2010-09-23 21:29:57 UTC

Hi -

Post by Roland McGrath