From e5823f1cb51a024d11a2953dc3a07af99439b261 Mon Sep 17 00:00:00 2001 From: Pedro Alves Date: Thu, 27 Jun 2013 19:17:27 +0000 Subject: [PATCH] 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 * gdbint.texinfo (Algorithms) : New section, based on infrun.c comment. gdb/ 2013-06-27 Pedro Alves * infrun.c: Remove comment describing the 'stepping over runtime loader dynamic symbol resolution code' mechanism; moved to gdbint.texinfo. --- gdb/ChangeLog | 6 ++++++ gdb/doc/ChangeLog | 6 ++++++ gdb/doc/gdbint.texinfo | 45 ++++++++++++++++++++++++++++++++++++++++++ gdb/infrun.c | 40 ------------------------------------- 4 files changed, 57 insertions(+), 40 deletions(-) diff --git a/gdb/ChangeLog b/gdb/ChangeLog index 889097fd1f..8cb93e3235 100644 --- a/gdb/ChangeLog +++ b/gdb/ChangeLog @@ -1,3 +1,9 @@ +2013-06-27 Pedro Alves + + * infrun.c: Remove comment describing the 'stepping over runtime + loader dynamic symbol resolution code' mechanism; moved to + gdbint.texinfo. + 2013-06-27 Pedro Alves * exceptions.c (catch_command_errors): Remove spurious space. diff --git a/gdb/doc/ChangeLog b/gdb/doc/ChangeLog index 27d37bd6ed..afd66e6383 100644 --- a/gdb/doc/ChangeLog +++ b/gdb/doc/ChangeLog @@ -1,3 +1,9 @@ +2013-06-27 Pedro Alves + + * gdbint.texinfo (Algorithms) : New section, based on infrun.c + comment. + 2013-06-26 Tom Tromey * gdbint.texinfo (Versions and Branches): Use common/version.in. diff --git a/gdb/doc/gdbint.texinfo b/gdb/doc/gdbint.texinfo index 8f826117f5..749e121332 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 84e405327a..8fb219a5cd 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. */ -- 2.34.1