Re: [PATCH 0/8] Non-contiguous address range support

[Kevin Buettner <kevinb@redhat.com>]

On Thu, 19 Jul 2018 11:55:48 -0400
Simon Marchi <simon.marchi@polymtl.ca> wrote:

> On 2018-07-16 22:00, Kevin Buettner wrote:
> > Hi Simon,
> > 
> > I haven't tried the simpler caching approach that you outline above.
> > It seems like it should work and it would definitely make checking for
> > whether or not something is in the cache simpler.
> > 
> > I'll give it a try and run the test suite to see if there's a problem 
> > with
> > doing it that way.
> > 
> > Thanks,
> > 
> > Kevin  
> 
> Just note that I don't have the complete picture yet.  If the block 
> range information is necessary for some other reason, then it would make 
> sense to use it as well for that cache.  I didn't want to send you on a 
> long side-quest for nothing!

Hi Simon,

The block range information is still required for several other reasons.
One obvious case is that we need to iterate through the ranges for
displaying disassembly.

However, I really liked your suggestion because we can retain the simple
test for determining whether or not PC is in the cache:

  if (mapped_pc >= cache_pc_function_low
      && mapped_pc < cache_pc_function_high
      && section == cache_pc_function_section)
    goto return_cached_value;

I've posted a replacement for patch 3/8 which uses your approach. 
Note that the block range information is still used within that patch
for determining the low and high addresses for the cache.

What's not in that patch is the removal of block_contains_pc which
was added in patch 1/8.  The only caller of this function was in
my earlier patch for find_pc_partial_function (in 3/8).  It's no
longer needed.

I'm guessing that you'll have some suggestions which will require
a v2 patch series.  I'll wait to show the removal of block_contains_pc
until that time.

Thanks for looking at this...

Kevin