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

Tom Tromey
2025-10-27T23:01:44Z

>>>>> "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