From: Tom Tromey <tom@tromey.com>
To: Jan Vrany <jan.vrany@labware.com>
Cc: gdb-patches@sourceware.org
Subject: Re: [PATCH 5/7] gdb: update blockvector::lookup to handle non-contiguous blocks
Date: Thu, 19 Feb 2026 13:20:39 -0700 [thread overview]
Message-ID: <87wm0832p4.fsf@tromey.com> (raw)
In-Reply-To: <20260219185638.360694-6-jan.vrany@labware.com> (Jan Vrany's message of "Thu, 19 Feb 2026 18:56:36 +0000")
>>>>> "Jan" == Jan Vrany <jan.vrany@labware.com> writes:
Jan> This commit updates blockvector::lookup to handle non-contiguous without
Jan> help of addrmap. It introduces a new method, block::contains(CORE_ADDR),
Jan> to check whether given block contains given address. This new method is
Jan> then used in blockvector::lookup instead of simply using block's
Jan> start and end addresses.
Jan> A unit test for non-contiguous blocks will come later in this series.
Jan> On Debian x86_64 I see no regressions except
Jan> FAIL: gdb.dwarf2/debug-names.exp: print _start
Jan> This is caused by discrepancy between the debug info and the debug names
Jan> and will be eventually fixed in a separate patch.
I glossed over this before but is this patch in this series?
Jan> +bool
Jan> +block::contains (const CORE_ADDR addr) const
Jan> +{
Jan> + if (addr >= start () && addr < end ())
Jan> + {
Jan> + if (is_contiguous ())
Jan> + return true;
Jan> +
Jan> + for (auto range : ranges ())
Jan> + {
Jan> + if (range.start () <= addr && addr < range.end ())
Jan> + return true;
It took me a long time to understand that this patch was doing the real
work in this series...
For this method I guess there is an invariant that the block's start is
the minimum of the range minima and the block's end is the maximum of
the range maxima.
It seems to me that since this is an important feature, it ought to be
enforced by an assert, if necessary adding checks in the reader to
ensure that bad DWARF doesn't cause an assertion failure.
Jan> @@ -857,7 +876,10 @@ blockvector::lookup (CORE_ADDR addr) const
Jan> if (b->start () > addr)
Jan> return nullptr;
Jan> if (b->end () > addr)
Jan> - return b;
Jan> + {
Jan> + if (b->contains (addr))
Jan> + return b;
Jan> + }
Jan> bot--;
Jan> }
The heart of the series.
I wonder about the efficiency of this. Like how many blocks can we
expect to see in the linear phase?
I don't know what a representative program might be here.
Tom
next prev parent reply other threads:[~2026-02-19 20:21 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-02-19 18:56 [PATCH 0/7] Remove addrmap from blockvector Jan Vrany
2026-02-19 18:56 ` [PATCH 1/7] gdb: implement readnow_functions::find_pc_sect_compunit_symtab Jan Vrany
2026-02-19 20:01 ` Tom Tromey
2026-02-20 12:36 ` Jan Vraný
2026-02-20 14:25 ` Tom Tromey
2026-02-20 15:57 ` Jan Vraný
2026-02-19 18:56 ` [PATCH 2/7] gdb: update expanded_symbols_functions::find_pc_sect_compunit_symtab Jan Vrany
2026-02-19 20:02 ` Tom Tromey
2026-02-19 18:56 ` [PATCH 3/7] gdb: simplify find_compunit_symtab_for_pc_sect Jan Vrany
2026-02-19 20:02 ` Tom Tromey
2026-02-20 12:40 ` Jan Vraný
2026-02-20 14:25 ` Tom Tromey
2026-02-26 15:00 ` Jan Vraný
2026-02-19 18:56 ` [PATCH 4/7] gdb: do not set blockvector address map Jan Vrany
2026-02-19 20:03 ` Tom Tromey
2026-02-20 12:42 ` Jan Vraný
2026-02-19 18:56 ` [PATCH 5/7] gdb: update blockvector::lookup to handle non-contiguous blocks Jan Vrany
2026-02-19 20:06 ` Tom Tromey
2026-02-19 20:20 ` Tom Tromey [this message]
2026-02-20 13:03 ` Jan Vraný
2026-02-20 16:38 ` Tom Tromey
2026-03-03 11:06 ` Jan Vraný
2026-03-09 15:52 ` Jan Vraný
2026-02-19 18:56 ` [PATCH 6/7] gdb: remove address map from struct blockvector Jan Vrany
2026-02-19 18:56 ` [PATCH 7/7] gdb: add unit test for blockvector::lookup of non-contiguous blocks Jan Vrany
2026-02-19 20:12 ` 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=87wm0832p4.fsf@tromey.com \
--to=tom@tromey.com \
--cc=gdb-patches@sourceware.org \
--cc=jan.vrany@labware.com \
/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