From: Markus Metzger <markus.t.metzger@intel.com>
To: gdb-patches@sourceware.org
Cc: palves@redhat.com
Subject: [PATCH 3/5] btrace: update tail call heuristic
Date: Fri, 22 Jul 2016 08:12:00 -0000 [thread overview]
Message-ID: <1469175120-19657-4-git-send-email-markus.t.metzger@intel.com> (raw)
In-Reply-To: <1469175120-19657-1-git-send-email-markus.t.metzger@intel.com>
An unconditional jump to the start of a function typically indicates a tail
call.
If we can't determine the start of the function at the destination address, we
used to treat it as a tail call, as well. This results in lots of tail calls
for code for which we don't have symbol information.
Restrict the heuristic to only consider jumps as tail calls that switch
functions in the case where we can't determine the start of a function. This
effectively disables tail call detection for code without symbol information.
2016-07-22 Markus Metzger <markus.t.metzger@intel.com>
gdb/
* btrace.c (ftrace_update_function): Update tail call heuristic.
---
gdb/btrace.c | 11 +++++++++--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/gdb/btrace.c b/gdb/btrace.c
index e0d0f27..e817f09 100644
--- a/gdb/btrace.c
+++ b/gdb/btrace.c
@@ -528,10 +528,17 @@ ftrace_update_function (struct btrace_function *bfun, CORE_ADDR pc)
start = get_pc_function_start (pc);
+ /* A jump to the start of a function is (typically) a tail call. */
+ if (start == pc)
+ return ftrace_new_tailcall (bfun, mfun, fun);
+
/* If we can't determine the function for PC, we treat a jump at
- the end of the block as tail call. */
- if (start == 0 || start == pc)
+ the end of the block as tail call if we're switching functions
+ and as an intra-function branch if we don't. */
+ if (start == 0 && ftrace_function_switched (bfun, mfun, fun))
return ftrace_new_tailcall (bfun, mfun, fun);
+
+ break;
}
}
}
--
1.8.3.1
next prev parent reply other threads:[~2016-07-22 8:12 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-07-22 8:12 [PATCH 0/5] improve trace gap handling Markus Metzger
2016-07-22 8:12 ` [PATCH 5/5] btrace: bridge gaps Markus Metzger
2016-07-22 8:12 ` [PATCH 4/5] btrace: preserve function level for unexpected returns Markus Metzger
2016-07-22 8:12 ` [PATCH 2/5] btrace: allow leading trace gaps Markus Metzger
2016-07-22 8:12 ` Markus Metzger [this message]
2016-10-27 10:59 ` [PATCH 0/5] improve trace gap handling Yao Qi
2016-10-27 12:39 ` Metzger, Markus T
2016-10-27 15:04 ` Yao Qi
2016-10-27 15:11 ` Pedro Alves
2016-10-28 7:11 ` Metzger, Markus T
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=1469175120-19657-4-git-send-email-markus.t.metzger@intel.com \
--to=markus.t.metzger@intel.com \
--cc=gdb-patches@sourceware.org \
--cc=palves@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