|
From: Philippe W. <phi...@sk...> - 2010-06-02 05:24:43
|
> I more or less only counted the low-level features needed. > Why can't we start off with the external notifications be a feature > on top of the low-level services, independent from gdbserver? > As this is an internal protocol, we can change it when we decide to merge > gdbserver later (even with VG releases inbetween). For sure, the framework provided by gdbserver stuff is too heavy for just the objective of improving (at short term) the way callgrind is waken up. The ptrace basis can be kept for that, but the current way with which VG gives info to vgdb (FIFOs, shared mem) can probably be replaced by a simpler mechanism (e.g. callgrind could write in a file the needed info such as the address to invoke, where the list of VG threads are, etc). > My suggestion was not to get rid of (1), as (2) sometimes forwards the request to (1). > > The question was more: if I know that I am on a system with ptrace working (simply check the > version of the running linux kernel), there is no reason to first do (1), and after 100ms (2). > I always could directly start with (2), getting rid of the 100ms latency (?). For gdbserver (gdb debugging VG through vgdb relay), I think that in most cases, VG will read the data sent by vgdb faster than if trying to waking it up via ptrace, SIGSTOP, suspend all threads, invoke reading code, resume the threads (as all this are heavy operations) : the "lightweight" polling can be done often enough so that a "running" VG (which is what happens most of the time) will react directly. If the latency is annoying for some applications, effectively, your suggestion is worth trying. What you suggest above can be somewhat tested by giving to VG a huge --vgdb-poll parameter and giving --max-invoke-ms=1 to vgdb. |