|
From: Philippe W. <phi...@sk...> - 2010-06-01 20:28:46
|
>> 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)
m_gdbserver.c, pub_core_gdbserver.h, pub_tool_gdbserver.h : about 1500 lines (3 new files).
These 3 files are providing the interface between the rest of valgrind and the gdbserver "protocol box"
(including the "instrument an SBB block for gdbserver").
The protocol box (recuperated from gdb, with small modifications) is a bunch of files, total about 9000 lines.
valgrind*low*.[hc] is about 1500 lines, implementing the interface between the protocol box
and the "VG platform/architecture" (i.e. find the list of threads; read/write memory or registers, ...).
For this, only x86 and amd64 are done, ppc32 and ppc64 files are just stubs. For each new
processor, a file of about 300 lines is needed.
There are about 900 lines of xml files to describe the valgrind shadow registers so that gdb
is made aware of these VG shadow registers (xml also currently only done for x86 and amd64).
The "pure" ptrace external notification and code invocation part is not big, but makes usage of the
infrastructure provided by the rest of the gdbserver patch (e.g. the protocol, the shared memory).
This is e.g. what ensures that an external notification can be done either from a
"standalone vgdb" or from gdb (via the "qRcmd" monitor gdbserver protocol packet).
For example, the memcheck mc.leak_check can be executed from inside gdb (when the
VG process is being debugged) or by doing in a shell the command "vgdb mc.leak_check".
Ths same code in VG will be executed in both cases, the last one only uses a very small
part of the gdbserver protocol.
>
> 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.
* it is only possible to directly invoke some VG core code with ptrace if VG code is currently
not being executed as the VG core code is not (always) re-entrant code.
So, some sort of polling is any case needed for a process always executing code : no way
we can always directly invoke some code, as the current piece of code might not be
re-entrant.
* finally, I guess not all OS will have the same sophistication as the linux syscall restart after
ptrace. So, for such OS, keeping a functional polling fallback is a good idea.
And if ever in very special cases, the ptrace mechanism would not be transparent, then the
"simple" polling (but which is efficient as this is just reading and comparing a counter from
time to time) will work properly for most applications.
Philippe
|