Move comment on the 'stepping over resolver' mechanism to the internals manual.

[deliverable/binutils-gdb.git] / gdb / doc / gdbint.texinfo

diff --git a/gdb/doc/gdbint.texinfo b/gdb/doc/gdbint.texinfo
index 8f826117f5e1a317c21e673a408cacea87308474..749e121332b5341f45024ece3e614e5d610ad0af 100644 (file)
--- a/gdb/doc/gdbint.texinfo
+++ b/gdb/doc/gdbint.texinfo
@@ -592,6 +592,51 @@ but @code{placed_size} may be.
 
 @section Single Stepping
 
+@section Stepping over runtime loader dynamic symbol resolution code
+@cindex Procedure Linkage Table, stepping over
+@cindex PLT, stepping over
+@cindex resolver, stepping over
+
+If the program uses ELF-style shared libraries, then calls to
+functions in shared libraries go through stubs, which live in a table
+called the PLT (@dfn{Procedure Linkage Table}).  The first time the
+function is called, the stub sends control to the dynamic linker,
+which looks up the function's real address, patches the stub so that
+future calls will go directly to the function, and then passes control
+to the function.
+
+If we are stepping at the source level, we don't want to see any of
+this --- we just want to skip over the stub and the dynamic linker.
+The simple approach is to single-step until control leaves the dynamic
+linker.
+
+However, on some systems (e.g., Red Hat's 5.2 distribution) the
+dynamic linker calls functions in the shared C library, so you can't
+tell from the PC alone whether the dynamic linker is still running.
+In this case, we use a step-resume breakpoint to get us past the
+dynamic linker, as if we were using @code{next} to step over a
+function call.
+
+The @code{in_solib_dynsym_resolve_code} function says whether we're in
+the dynamic linker code or not.  Normally, this means we single-step.
+However, if @code{gdbarch_skip_solib_resolver} then returns non-zero,
+then its value is an address where we can place a step-resume
+breakpoint to get past the linker's symbol resolution function.
+
+The @code{in_dynsym_resolve_code} hook of the @code{target_so_ops}
+vector can generally be implemented in a pretty portable way, by
+comparing the PC against the address ranges of the dynamic linker's
+sections.
+
+The @code{gdbarch_skip_solib_resolver} implementation is generally
+going to be system-specific, since it depends on internal details of
+the dynamic linker.  It's usually not too hard to figure out where to
+put a breakpoint, but it certainly isn't portable.
+@code{gdbarch_skip_solib_resolver} should do plenty of sanity
+checking.  If it can't figure things out, returning zero and getting
+the (possibly confusing) stepping behavior is better than signaling an
+error, which will obscure the change in the inferior's state.  */
+
 @section Signal Handling
 
 @section Thread Handling