diff options
author | Pedro Alves <palves@redhat.com> | 2013-06-26 21:37:53 +0000 |
---|---|---|
committer | Pedro Alves <palves@redhat.com> | 2013-06-26 21:37:53 +0000 |
commit | 7b624e71365424e79d4e9d18eee2d213af9e484b (patch) | |
tree | d15381fbd1f7d0b7b6c462cdcf60e254dbd83e0c /gdb/infrun.c | |
parent | 74e5a34656bca58b23274307778613f14bb77bbd (diff) | |
download | gdb-7b624e71365424e79d4e9d18eee2d213af9e484b.zip gdb-7b624e71365424e79d4e9d18eee2d213af9e484b.tar.gz gdb-7b624e71365424e79d4e9d18eee2d213af9e484b.tar.bz2 |
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.
Diffstat (limited to 'gdb/infrun.c')
-rw-r--r-- | gdb/infrun.c | 32 |
1 files changed, 16 insertions, 16 deletions
diff --git a/gdb/infrun.c b/gdb/infrun.c index 720c4ed..d36d2e0 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 |