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

[external/binutils.git] / gdb / infrun.c

diff --git a/gdb/infrun.c b/gdb/infrun.c
index 84e4053..8fb219a 100644 (file)
--- a/gdb/infrun.c
+++ b/gdb/infrun.c
@@ -181,46 +181,6 @@ set_disable_randomization (char *args, int from_tty,
             "this platform."));
 }
 
-
-/* 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 (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 "next" to step over a
-   function call.
-
-   in_solib_dynsym_resolve_code() says whether we're in the dynamic
-   linker code or not.  Normally, this means we single-step.  However,
-   if 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 in_dynsym_resolve_code hook of the 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 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.
-   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.  */
-
 /* "Observer mode" is somewhat like a more extreme version of
    non-stop, in which all GDB operations that might affect the
    target's execution have been disabled.  */