Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Tom Tromey <tom@tromey.com>
To: Simon Marchi <simon.marchi@efficios.com>
Cc: gdb-patches@sourceware.org
Subject: Re: [PATCH] gdb/dwarf2: don't search included symtabs recursively
Date: Thu, 05 Feb 2026 11:53:33 -0700	[thread overview]
Message-ID: <87ldh758eq.fsf@tromey.com> (raw)
In-Reply-To: <20260203173640.215967-1-simon.marchi@efficios.com> (Simon Marchi's message of "Tue, 3 Feb 2026 12:36:27 -0500")

>>>>> "Simon" == Simon Marchi <simon.marchi@efficios.com> writes:

Simon> It therefore seems unnecessary to do a recursive search, in
Simon> recursively_find_pc_sect_compunit_symtab, it will search some symtabs
Simon> multiple times.

Agreed, thanks for finding this.

We discussed this elsewhere but probably what we eventually want is a
mechanism to avoid searching included symtabs more than once across an
entire search.

Simon> I am not sure how blockvectors work exactly, whether the blockvector of
Simon> the includer CU is a superset of the blockvectors of the includees.  I
Simon> ask that because it seems like in practice, the requested PC always
Simon> seems to be found in the first searched CU.  I haven't investigated this
Simon> point more than that though.

I think each compunit_symtab gets a blockvector that describes exactly
the functions defined locally in that CU.

It would be very unusual for a partial unit to really contain code.  The
reason for this is that the normal reason to make a partial unit is to
share common things between CUs, but two CUs would not normally describe
the same function with the same address ranges.  It wouldn't be invalid
to do this, just not very useful.

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

Tom

  reply	other threads:[~2026-02-05 18:54 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-01-30  2:55 [PATCH 1/3] gdb/block: make find_iterator_compunit_symtab a method of block_iterator simon.marchi
2026-01-30  2:55 ` [PATCH 2/3] gdb/symtab: make compunit_symtab::includes a std::vector simon.marchi
2026-02-05 18:38   ` Tom Tromey
2026-01-30  2:55 ` [PATCH 3/3] gdb/block: bool-ify some parameters simon.marchi
2026-02-03 17:36   ` [PATCH] gdb/dwarf2: don't search included symtabs recursively Simon Marchi
2026-02-05 18:53     ` Tom Tromey [this message]
2026-02-05 19:36       ` Simon Marchi
2026-02-05 18:38   ` [PATCH 3/3] gdb/block: bool-ify some parameters Tom Tromey
2026-02-05 17:41 ` [PATCH 1/3] gdb/block: make find_iterator_compunit_symtab a method of block_iterator Tom Tromey
2026-02-05 19:33   ` Simon Marchi
2026-02-05 18:46 ` Tom Tromey
2026-02-05 19:17   ` 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=87ldh758eq.fsf@tromey.com \
    --to=tom@tromey.com \
    --cc=gdb-patches@sourceware.org \
    --cc=simon.marchi@efficios.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