From 7b624e71365424e79d4e9d18eee2d213af9e484b Mon Sep 17 00:00:00 2001 From: Pedro Alves Date: Wed, 26 Jun 2013 21:37:53 +0000 Subject: [PATCH] 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 * infrun.c: Update comments on stepping over runtime loader dynamic symbol resolution code. --- gdb/ChangeLog | 5 +++++ gdb/infrun.c | 32 ++++++++++++++++---------------- 2 files changed, 21 insertions(+), 16 deletions(-) diff --git a/gdb/ChangeLog b/gdb/ChangeLog index b513c4082ac..af5027386ba 100644 --- a/gdb/ChangeLog +++ b/gdb/ChangeLog @@ -1,3 +1,8 @@ +2013-06-26 Pedro Alves + + * infrun.c: Update comments on stepping over runtime loader + dynamic symbol resolution code. + 2013-06-26 Sergio Durigan Junior * ax-gdb.h (union exp_element): Forward declare. diff --git a/gdb/infrun.c b/gdb/infrun.c index 720c4ed07dc..d36d2e04244 100644 --- 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 -- 2.30.2