From: Tom Tromey <tromey@adacore.com>
To: gdb-patches@sourceware.org
Subject: [PATCH 0/6] Handle split functions in call site chains
Date: Wed, 1 Dec 2021 15:04:26 -0700 [thread overview]
Message-ID: <20211201220432.4105152-1-tromey@adacore.com> (raw)
This series fixes a bug in DW_OP_entry_value handling.
A large customer program that is compiled with optimization has a
function that is split into hot and cold parts. The DWARF uses
DW_AT_ranges to represent this.
However, the call site code only looks at the low and high PCs. This
means that the entry value computation fails to find the correct outer
frame, and so cannot evaluate a certain local variable.
This series changes the code to record multiple addresses in a call
site target. This change lets this particular case work.
Some of this series is refactoring to make it simpler to deal with
call_site_target.
Patch #4 could use an extra examination, both because I convert
explicit state management to recursion (IMO ok because these call
chains tend to be short); but also because I think I found a bug in
the current code.
Regression tested on x86-64 Fedora 34.
Let me know what you think.
Tom
next reply other threads:[~2021-12-01 22:04 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-12-01 22:04 Tom Tromey [this message]
2021-12-01 22:04 ` [PATCH 1/6] Change call_site_target to use custom type and enum Tom Tromey
2021-12-01 22:04 ` [PATCH 2/6] Make call_site_target members private Tom Tromey
2021-12-01 22:04 ` [PATCH 3/6] Constify chain_candidate Tom Tromey
2021-12-01 22:04 ` [PATCH 4/6] Change call_site_find_chain_1 to work recursively Tom Tromey
2021-12-01 22:04 ` [PATCH 5/6] Change call_site_target to iterate over addresses Tom Tromey
2021-12-01 22:04 ` [PATCH 6/6] Handle multiple addresses in call_site_target Tom Tromey
2022-02-28 18:34 ` [PATCH 0/6] Handle split functions in call site chains Tom Tromey
2022-03-28 19:54 ` Tom Tromey
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=20211201220432.4105152-1-tromey@adacore.com \
--to=tromey@adacore.com \
--cc=gdb-patches@sourceware.org \
/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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).