Re: [RFC] [PATCH] In-kernel gdbstub based on utrace Infrastructure.
Ingo Molnar mi...@elte.hu writes: [...] Since the speed of development in this area is truly glacial at the moment and the practical advantages that i can experience personally (directly as a Linux user and indirectly as a maintainer) are miniscule so far, caution is warranted IMO. [...] If the caution you suggest is operationally equivalent to discouraging even miniscule improvements, is it any wonder that progress is glacial? The gdbstub prototype was constructed for two reasons: to demonstrate utrace usage now, and in the future to be incrementally useful (over ptrace, by moving into fast kernel-space operations like multithreading control, gdb-tracepoint support, other stuff). #1 is about done. With respect to #2, we can certainly commit to ongoing work on improvements, provided the community shows interest and goodwill. - FChE
Re: Tests Failures on PPC64
On 12/10, Oleg Nesterov wrote: On 12/09, CAI Qian wrote: - Oleg Nesterov o...@redhat.com wrote: Thanks, but it doesn't fail for me on this machine... Hmm, it failed for me. # cd /root/ptrace-tests # make check ... FAIL: watchpoint OMG. Yet another test-case fails on powerpc I didn't see this failure in the previous reports or missed it ... I bet it fails without utrace too? (please don't tell it doesn't ;) Did you see it fails on other ppc64 machines? Oh well. I spent this day grepping arch/powerpc to understand how PTRACE_SET_DEBUGREG works and what is the problem. But I am afraid this time I need a help from someone who understands the hardware magic on powerpc. So far: - the test-case looks correct to me OOPS. I am not sure, will re-check tomorrow. But it seems to me gcc optimizes out check = 1, despite the fact it is declared as volatile. Oleg.
Re: Tests Failures on PPC64
I bet it fails without utrace too? (please don't tell it doesn't ;) Yes. Did you see it fails on other ppc64 machines? No. Ah. I didn't notice you did biarch-check, not check. Will take a look later... Thanks in advance, CAI Qian
Re: [RFC] [PATCH] In-kernel gdbstub based on utrace Infrastructure.
Hi - On Thu, Dec 10, 2009 at 07:16:38PM +0100, Ingo Molnar wrote: [...] The gdbstub prototype was constructed for two reasons: to demonstrate utrace usage now, and in the future to be incrementally useful (over ptrace, by moving into fast kernel-space operations like multithreading control, gdb-tracepoint support, other stuff). [...] What i'd like to see is measurable benefits to users, developers and maintainers. OK, it's clear that in the gdb-stub's case, some positive motivation beyond it being an api-educational example would be appropriate before merging. Note that it was only an RFC at the time. I'd like to see the same for SystemTap too btw. systemtap's benefits are beyond question to its users. (Others are worried about systemtap problems, but that wasn't your question.) In what form do you expect to see such measurements? It would help if you could point out prior examples of such measurable benefit analyses that perchance accompanied other then-new kernel features, say in the tracing/debugging area. - FChE
Re: Tests Failures on PPC64
On Thu, Dec 10, 2009 at 08:24:36PM +0100, Oleg Nesterov wrote: On 12/09, CAI Qian wrote: - Oleg Nesterov o...@redhat.com wrote: Thanks, but it doesn't fail for me on this machine... Hmm, it failed for me. # cd /root/ptrace-tests # make check ... FAIL: watchpoint OMG. Yet another test-case fails on powerpc I didn't see this failure in the previous reports or missed it ... I bet it fails without utrace too? (please don't tell it doesn't ;) Did you see it fails on other ppc64 machines? Oh well. I spent this day grepping arch/powerpc to understand how PTRACE_SET_DEBUGREG works and what is the problem. But I am afraid this time I need a help from someone who understands the hardware magic on powerpc. There's relatively less magic with PPC64 (with just one DABR) compared to x86 :-) I hope to offer a little help here (given that I work to tweak ptrace_set_debugreg() in PPC64 to use the hw-breakpoint interfaces) Watchpoints (using DABR) through GDB can fail for many reasonsthey must ideally be set after the program has started execution - to enable GDB know the size of the variable...else they would resort to single-stepping to trap access to the target variable. Cai, Where can one find the relevant piece of testcase? Thanks, K.Prasad
