From: Randolph Chung <randolph@tausq.org>
To: gdb@sources.redhat.com
Subject: [patch/rfc] How to handle stepping into an unresolved plt entry?
Date: Fri, 21 May 2004 06:44:00 -0000 [thread overview]
Message-ID: <20040521064435.GJ566@tausq.org> (raw)
On hppa, I noticed that when I do a "step" over an indirect function
call, gdb does not stop inside the called function. I've traced the
problem down to the following:
An indirect function call on hppa goes through a stub ($$dyncall).
$$dyncall loads a PLABEL from the PLT and jumps to it. In the case that
the PLT is not yet resolved, we need to do the normal PLT fixup () in
the loader before calling the function.
What seems to be happening now is that when a "step" happens at the
indirect function call, we step into the $$dyncall stub, and in
infrun.c, we do a SKIP_TRAMPOLINE_CODE. This resolves into a pc that
points at the fixup routine. Next, in handle_inferior_event (), we try
to lookup the file/line information for this target pc; it's not found,
and so gdb just goes ahead and insert a breakpoint at the return address
of the stub (which is in the caller) and then calls keep_going ().
If we do a step on a second invocation of the indirect function call, it
works correctly; SKIP_TRAMPOLINE_CODE resolves to an address that points
to the target function, so the file/line lookup works and we insert a
breakpoint in the right place.
What is actually supposed to happen in this case? The documentation says:
@findex SKIP_TRAMPOLINE_CODE
If the target machine has trampoline code that sits between callers and
the functions being called, then define this macro to return a new PC
that is at the start of the real function.
But how do you do this if your target address is not yet resolved? The
attached patch gives a workaround for this problem (also needs a small
fix to the target code), but it seems a bit clumsy to me.... it's not
like handle_inferior_event () needs any more special cases... :-(
Comments? Suggestions?
thanks
randolph
--
Randolph Chung
Debian GNU/Linux Developer, hppa/ia64 ports
http://www.tausq.org/
2004-05-20 Randolph Chung <tausq@debian.org>
* infrun.c (handle_inferior_event): If skipping a trampoline results
in an address in the resolver, stop there before continuing.
* hppa-linux-tdep.c (hppa_linux_skip_trampoline_code): Handle the
case when the plabel points to a PLT stub.
Index: infrun.c
===================================================================
RCS file: /cvs/src/src/gdb/infrun.c,v
retrieving revision 1.163
diff -u -p -r1.163 infrun.c
--- infrun.c 14 May 2004 18:45:42 -0000 1.163
+++ infrun.c 21 May 2004 06:36:36 -0000
@@ -2435,6 +2443,24 @@ process_event_stop_test:
}
}
+ /* If skipping a trampoline results in an address in the resolver,
+ stop there before continuing. */
+ if (IN_SOLIB_DYNSYM_RESOLVE_CODE (ecs->stop_func_start))
+ {
+ struct symtab_and_line sr_sal;
+ init_sal (&sr_sal);
+ sr_sal.pc = ecs->stop_func_start;
+
+ check_for_old_step_resume_breakpoint ();
+ step_resume_breakpoint =
+ set_momentary_breakpoint (sr_sal, null_frame_id, bp_step_resume);
+ if (breakpoints_inserted)
+ insert_breakpoints ();
+
+ keep_going (ecs);
+ return;
+ }
+
/* If we have no line number and the step-stop-if-no-debug is
set, we stop the step so that the user has a chance to switch
in assembly mode. */
Index: hppa-linux-tdep.c
===================================================================
RCS file: /cvs/src/src/gdb/hppa-linux-tdep.c,v
retrieving revision 1.5
diff -u -p -r1.5 hppa-linux-tdep.c
--- hppa-linux-tdep.c 8 May 2004 03:59:34 -0000 1.5
+++ hppa-linux-tdep.c 21 May 2004 06:36:36 -0000
@@ -219,6 +211,24 @@ hppa_linux_skip_trampoline_code (CORE_AD
if (pc & 0x2)
pc = (CORE_ADDR) read_memory_integer (pc & ~0x3, TARGET_PTR_BIT / 8);
+ /* if the plt slot has not yet been resolved, the target will
+ be the plt stub */
+ if (in_plt_section (pc, NULL))
+ {
+ /* Sanity check: are we pointing to the plt stub? */
+ if (insns_match_pattern (pc, hppa_plt_stub, insn))
+ {
+ /* this should point to the fixup routine */
+ pc = (CORE_ADDR) read_memory_integer (pc + 8, TARGET_PTR_BIT / 8);
+ }
+ else
+ {
+ error ("Cannot resolve plt stub at 0x%s\n",
+ paddr_nz (pc));
+ pc = 0;
+ }
+ }
+
return pc;
}
next reply other threads:[~2004-05-21 6:44 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-05-21 6:44 Randolph Chung [this message]
2004-05-21 16:00 ` Andrew Cagney
2004-05-21 18:21 ` Randolph Chung
2004-05-24 17:32 ` Andrew Cagney
2004-05-24 18:52 ` Randolph Chung
2004-05-25 7:13 ` Randolph Chung
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20040521064435.GJ566@tausq.org \
--to=randolph@tausq.org \
--cc=gdb@sources.redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox