Menu
▾
▴
[Valgrind-developers] valgrind: r5297 - in branches/FNWRAP/coregrind: . m_demangle
|
From: <sv...@va...> - 2005-12-06 18:19:06
|
Author: sewardj
Date: 2005-12-06 18:18:56 +0000 (Tue, 06 Dec 2005)
New Revision: 5297
Log:
Add comments re redirection and demangling.
Modified:
branches/FNWRAP/coregrind/m_demangle/demangle.c
branches/FNWRAP/coregrind/m_redir.c
branches/FNWRAP/coregrind/m_translate.c
Modified: branches/FNWRAP/coregrind/m_demangle/demangle.c
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- branches/FNWRAP/coregrind/m_demangle/demangle.c 2005-12-06 17:27:44 U=
TC (rev 5296)
+++ branches/FNWRAP/coregrind/m_demangle/demangle.c 2005-12-06 18:18:56 U=
TC (rev 5297)
@@ -38,7 +38,22 @@
#include "demangle.h"
#include "pub_core_libcprint.h"
=20
+/* The demangler's job is to take a raw symbol name and turn it into
+ something a Human Bean can understand. There are two levels of
+ mangling.
=20
+ 1. First, C++ names are mangled by the compiler. So we'll have to
+ undo that.
+
+ 2. Optionally, in relatively rare cases, the resulting name is then
+ itself encoded using Z-escaping (see pub_core_redir.h) so as to
+ become part of a redirect-specification.
+
+ Therefore, VG_(demangle) first tries to undo (2). If successful,
+ the soname part is discarded (humans don't want to see that).
+ Then, it tries to undo (1) (using demangling code from GNU/FSF).
+*/
+
/* This is the main, standard demangler entry point. */
=20
void VG_(demangle) ( Char* orig, Char* result, Int result_size )
Modified: branches/FNWRAP/coregrind/m_redir.c
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- branches/FNWRAP/coregrind/m_redir.c 2005-12-06 17:27:44 UTC (rev 5296=
)
+++ branches/FNWRAP/coregrind/m_redir.c 2005-12-06 18:18:56 UTC (rev 5297=
)
@@ -48,6 +48,49 @@
#include "pub_core_demangle.h" // VG_(maybe_Z_demangle)
=20
=20
+/* This module is a critical part of the redirection/intercept system.
+ It keeps track of the current intercept state, cleans up the
+ translation caches when that state changes, and finally, answers
+ queries about the whether an address is currently redirected or
+ not. It doesn't do any of the control-flow trickery needed to put
+ the redirections into practice. That is the job of m_translate,
+ which calls here to find out which translations need to be
+ redirected.
+
+ The interface is simple. VG_(redir_initialise) initialises and
+ loads some hardwired redirects which never disappear; this is
+ platform-specific.
+
+ The module is notified of redirection state changes by m_debuginfo.
+ That calls VG_(redir_notify_new_SegInfo) when a new SegInfo (shared
+ object symbol table, basically) appears. Appearance of new symbols
+ can cause new (active) redirections to appear for two reasons: the
+ symbols in the new table may match existing redirection
+ specifications (see comments below), and because the symbols in the
+ new table may themselves supply new redirect specifications which
+ match existing symbols (or ones in the new table).
+
+ Redirect specifications are really symbols with "funny" prefixes
+ (_vgrZU_ and _vgrZZ_). These names tell m_redir that the
+ associated code should replace the standard entry point for some
+ set of functions. The set of functions is specified by a (soname
+ pattern, function name pattern) pair which is encoded in the symbol
+ name following the prefix. The names use a Z-encoding scheme so
+ that they may contain punctuation characters and wildcards (*).
+ The encoding scheme is described in pub_tool_redir.h and is decoded
+ by VG_(maybe_Z_demangle).
+
+ When a shared object is unloaded, this module learns of it via a
+ call to VG_(redir_notify_delete_SegInfo). It then removes from its
+ tables all active redirections in any way associated with that
+ object, and tidies up the translation caches accordingly.
+
+ That takes care of tracking the redirection state. When a
+ translation is actually to be made, m_translate calls to
+ VG_(redir_do_lookup) in this module to find out if the
+ translation's address should be redirected.
+*/
+
/*------------------------------------------------------------*/
/*--- Semantics ---*/
/*------------------------------------------------------------*/
@@ -113,10 +156,8 @@
actually want to have a system that allows this, I propose this:
all changes to Specs are acceptable. But, when recomputing Active
following the change, if the same orig is bound to more than one
- redir, then all bindings for orig are thrown out (of Active) and a
- warning message printed. That's pretty much what we have at
- present anyway (warning, but no throwout; instead just keep the
- first).
+ redir, then the first binding for orig is retained, and all the
+ rest ignored.
=20
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Modified: branches/FNWRAP/coregrind/m_translate.c
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- branches/FNWRAP/coregrind/m_translate.c 2005-12-06 17:27:44 UTC (rev =
5296)
+++ branches/FNWRAP/coregrind/m_translate.c 2005-12-06 18:18:56 UTC (rev =
5297)
@@ -441,6 +441,9 @@
}
=20
=20
+/* Note: see comments at top of m_redir.c for the Big Picture on how
+ redirections are managed. */
+
Bool VG_(translate) ( ThreadId tid,=20
Addr64 orig_addr,
Bool debugging_translation,
|
