From: Kevin Buettner <kevinb@redhat.com>
To: gdb-patches@sourceware.org
Subject: Re: [PATCH v3 6/8] Introduce find_pc_partial_entry_range and use it in infrun.c
Date: Tue, 21 Aug 2018 17:50:00 -0000 [thread overview]
Message-ID: <20180821104957.22621602@pinnacle.lan> (raw)
In-Reply-To: <a51620e6-bf82-96dc-a5cd-a6ba3b67e6a7@ericsson.com>
On Tue, 21 Aug 2018 12:19:13 -0400
Simon Marchi <simon.marchi@ericsson.com> wrote:
> On 2018-08-20 06:45 PM, Kevin Buettner wrote:
> > An earlier version of this patch used the returned block in conjunction
> > with BLOCK_ENTRY_PC to set stop_func_start in fill_in_stop_func() in
> > infrun.c. While I think this was the correct thing to do, changes
> > to find_inferior_partial_function could potentially end up with
> > stop_func_end < stop_func_start, which is definitely wrong. For
> > this case, we want to set both stop_func_start and stop_func_end
> > to the start and end of the range containing the function's entry
> > pc.
> >
> > I think that this functionality will be useful in many other places
> > too - it probably ought to be used in all of the various prologue
> > analyzers in GDB.
> >
> > The change to infrun.c was simple: the call to find_pc_partial_function
> > was replaced with a call to find_pc_partial_entry_range. The difference
> > between these two functions is that find_pc_partial_entry_function
> > will (potentially) return the start and end address corresponding to
> > the range in which PC is found, but find_pc_partial_entry_range
> > will (again, potentially) return the start and end address of the
> > range containing the entry pc. find_pc_partial_function has the
> > property that *ADDRESS <= PC < *ENDADDR. This condition does not
> > necessarily hold for the outputs of find_pc_partial_entry_range.
> >
> > It should be noted that for functions which contain only a single
> > range, the outputs of find_pc_partial_{function,entry_range} are
> > identical.
> >
> > I think it might happen that find_pc_partial_entry_range will come
> > to be used in place of many of the calls to find_pc_partial_function
> > within GDB. Care must be taken in making this change, however, since
> > some of this code depends on the *ADDRESS <= PC < *ENDADDR property.
>
> This LGTM.
>
> I just find the naming of all these finc_pc_* funtions confusing, like
> what does the "partial" mean in "find_pc_partial_function"? Why does
> the new function name not include "function"? I don't really have a
> better alternative to suggest, but if there's a logic behind the new name
> I'd like to know it so I understand the naming scheme better.
I (also) don't understand the original intent/meaning behind the use of
"partial" in the name.
As noted elsewhere, I've made a change to what the return values
*ADDRESS and *ENDADDR refer to: the start and end address now refer
only to the part (range) of the function in which PC is found. So
that's what "partial" might now refer to, though I'll admit that I
hadn't put much thought into it until just now.
With regard to "find_pc_partial_entry_range", it seems to me that
"find_pc_partial_function_entry_range" is overly long. Maybe
"find_pc_function_entry_range" is better?
Kevin
next prev parent reply other threads:[~2018-08-21 17:50 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-08-20 22:25 [PATCH v3 0/8] Non-contiguous address range support Kevin Buettner
2018-08-20 22:34 ` [PATCH v3 1/8] Add block range data structure for blocks with non-contiguous address ranges Kevin Buettner
2018-08-20 22:37 ` [PATCH v3 2/8] Record explicit block ranges from dwarf2read.c Kevin Buettner
2018-08-20 22:39 ` [PATCH v3 3/8] Add support for non-contiguous blocks to find_pc_partial_function Kevin Buettner
2018-08-21 16:12 ` Simon Marchi
2018-08-20 22:41 ` [PATCH v3 4/8] Disassemble blocks with non-contiguous ranges Kevin Buettner
2018-08-20 22:43 ` [PATCH v3 5/8] Use BLOCK_ENTRY_PC in place of most uses of BLOCK_START Kevin Buettner
2018-08-20 22:46 ` [PATCH v3 6/8] Introduce find_pc_partial_entry_range and use it in infrun.c Kevin Buettner
2018-08-21 16:19 ` Simon Marchi
2018-08-21 17:50 ` Kevin Buettner [this message]
2018-08-21 18:23 ` Simon Marchi
2018-08-21 18:47 ` Kevin Buettner
2018-08-20 22:47 ` [PATCH v3 7/8] Relocate block range start and end addresses Kevin Buettner
2018-08-20 22:48 ` [PATCH v3 8/8] Test case for functions with non-contiguous ranges Kevin Buettner
2018-08-21 16:28 ` Simon Marchi
2018-08-21 16:29 ` [PATCH v3 0/8] Non-contiguous address range support Simon Marchi
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=20180821104957.22621602@pinnacle.lan \
--to=kevinb@redhat.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