Re: [PATCHv3 6/7] gdb: record block end addresses while parsing DIEs

[Tom Tromey <tom@tromey.com>]

>>>>> "Andrew" == Andrew Burgess <aburgess@redhat.com> writes:

Andrew> The solution I propose is to build a light weight, partial map, that
Andrew> only holds the interesting (inline) blocks.  This partial map is only
Andrew> needed between reading the DIE and applying the optimised code fixes,
Andrew> after which it is done with, and as a consequence we don't need to
Andrew> update this map as the optimised code fixes adjust block ranges, this
Andrew> makes the partial map cheaper.

This would also affect lazy expansion, I guess.  There I'd like to at
least have function bodies be expanded on demand.  So the handling would
have to be done on a per-function basis.

I wonder if it would make sense for me to apply that transform sooner
rather than later.  Like:

Andrew> +  /* The end addresses for some inline blocks.  For blocks with multiple
Andrew> +     sub-ranges, this is the end address of every sub-range within the
Andrew> +     block.  These are the inclusive end addresses, that is, these are the
Andrew> +     last addresses inside the block's ranges.  Only the first block that
Andrew> +     ends at any given address will be recorded.  */
Andrew> +  gdb::unordered_map<unrelocated_addr, struct block *> inline_block_ends;

... turn this into a pointer and then use a scoped_restore to set/reset
it when reading a function scope.

This idea makes me wonder what happens if a nested function is processed
while reading an outer function.  But I suppose it is "nothing" because
an inline function's end address for outer function F shouldn't matter
to inner function F.I.

Approved-By: Tom Tromey <tom@tromey.com>

Tom