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

[Eli Zaretskii <eliz at gnu dot org>]

> From: Pedro Alves <palves@redhat.com>
> Date: Wed, 26 Jun 2013 22:42:37 +0100
> 
> 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-26  Pedro Alves  <palves@redhat.com>
> 
> 	* gdbint.texinfo (Algorithms) <Stepping over runtime loader
> 	dynamic symbol resolution code>: New section, based on infrun.c
> 	comment.

Thanks.

> +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.  A @cindex entry for the same would also
be a good idea.

> +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.

> +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.

OK with those changes.