Update comments on stepping over resolver code.

This updates the comments on the step-over-resolver mechanism a bit,
adjusting it to refer to the gdbarch hooks instead of the old macros;
to mention the in_dynsym_resolve_code hook of the target_so_ops
vector; and to American English spelling (signalling->signaling).

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

	* infrun.c: Update comments on stepping over runtime loader
	dynamic symbol resolution code.

diff --git a/gdb/ChangeLog b/gdb/ChangeLog
index b513c4082ac9a52e60f59d372a257d7490a6d84f..af5027386ba87a2b47520430e1b4a984bc36feb3 100644 (file)
--- a/gdb/ChangeLog
+++ b/gdb/ChangeLog
@@ -1,3 +1,8 @@
+2013-06-26  Pedro Alves  <palves@redhat.com>
+
+       * infrun.c: Update comments on stepping over runtime loader
+       dynamic symbol resolution code.
+
 2013-06-26  Sergio Durigan Junior  <sergiodj@redhat.com>
 
        * ax-gdb.h (union exp_element): Forward declare.

diff --git a/gdb/infrun.c b/gdb/infrun.c
index 720c4ed07dc59dae47882c39133af52bfe844c8d..d36d2e04244e76ca418ffa30206e70c4aa9730a4 100644 (file)
--- a/gdb/infrun.c
+++ b/gdb/infrun.c
@@ -204,22 +204,22 @@ set_disable_randomization (char *args, int from_tty,
 
    in_solib_dynsym_resolve_code() says whether we're in the dynamic
    linker code or not.  Normally, this means we single-step.  However,
-   if 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.
-
-   in_solib_dynsym_resolve_code() can generally be implemented in a
-   pretty portable way, by comparing the PC against the address ranges
-   of the dynamic linker's sections.
-
-   SKIP_SOLIB_RESOLVER 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.  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
-   signalling an error, which will obscure the change in the
-   inferior's state.  */
+   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.  */
 
 /* This function returns TRUE if pc is the address of an instruction
    that lies within the dynamic linker (such as the event hook, or the