This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [DOC/RFA PATCH] Move comment on the 'stepping over resolver' mechanism to the internals manual.


On 06/27/2013 06:46 PM, Eli Zaretskii wrote:
> 
>> +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
> 
> I'd suggest to have "Procedure Linkage Table" in @dfn, as you are
> introducing new terminology.

Done.

> A @cindex entry for the same would also be a good idea.

Indeed, good idea.  Done.

>> +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
>                                        ^^^^^^
> @code{next}, as we use elsewhere in the manuals.

Done.

>> +The @code{in_solib_dynsym_resolve_code} says whether we're in the
>              ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> Is it a function or a variable?  We should say which is it.

Whoops, typo.  Yes, function.

> OK with those changes.

Thanks.  Applied, as below.

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

This whole comment is now a bit out of place.  I looked into moving it
to handle_inferior_event, close to where in_solib_dynsym_resolve_code
is used, but then there are 3 such places.  I then looked at
fragmenting it, pushing bits closer to the definitions of
in_solib_dynsym_resolve_code and gdbarch_skip_solib_resolver, but then
we'd lose the main advantage which is the overview.  In the end, I
realized this can fit nicely as internals manual material.

This could possibly be a subsection of a new "run control", or "source
stepping" or "stepping" or some such a bit more general section, but
we can do that when we have more related content...  Even the "single
stepping" section is presently empty...

gdb/doc/
2013-06-27  Pedro Alves  <palves@redhat.com>

	* gdbint.texinfo (Algorithms) <Stepping over runtime loader
	dynamic symbol resolution code>: New section, based on infrun.c
	comment.

gdb/
2013-06-27  Pedro Alves  <palves@redhat.com>

	* infrun.c: Remove comment describing the 'stepping over runtime
	loader dynamic symbol resolution code' mechanism; moved to
	gdbint.texinfo.
---
 gdb/doc/gdbint.texinfo |   45 +++++++++++++++++++++++++++++++++++++++++++++
 gdb/infrun.c           |   40 ----------------------------------------
 2 files changed, 45 insertions(+), 40 deletions(-)

diff --git a/gdb/doc/gdbint.texinfo b/gdb/doc/gdbint.texinfo
index 8f82611..749e121 100644
--- 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
diff --git a/gdb/infrun.c b/gdb/infrun.c
index 84e4053..8fb219a 100644
--- 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.  */


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]