|
From: Josef W. <Jos...@gm...> - 2010-06-01 23:28:08
|
On Tuesday 01 June 2010, Philippe Waroquiers wrote: > >> Josef, very approximately, how much of Philippe's patch is the external > >> notification part? 5% ? > > > > I would estimate more like 2%. By far the biggest part is the standalone gdb > > remote server (vgdb). > > vgdb.c is about 1500 lines (new file) > ... Ah, thanks for the very detailed correction! 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). > > As far as I understand, there are 2 mechanisms used for the notification: > > (1) regular polling while VG instrumented code is running (similar to callgrind) > > (2) ptrace calling a handler function in the VG process, which forwards a > > request to the polling mechanism, if it sees that a VG thread is active. > > Otherwise, the "ptrace handler" reacts on the request itself. > > For vgdb notifying VG, first (1) is tried, and if there is no answer after 100ms, then > > (2) is used. > > Philippe, is my understanding correct? > > > > Why not directly always do (2)? > > Your understanding is correct. > (2) is not the only mechanism kept (and not always done directly) because > * as discussed in the other mail, the ptrace mechanism does only work on recent linux kernel. > So, a fallback is needed for older linux kernel. 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 (?). Josef |