Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Kevin Buettner <kevinb@redhat.com>
To: Tom Tromey <tom@tromey.com>
Cc: gdb-patches@sourceware.org
Subject: Re: [PATCH] gdb/dwarf2: Add symbols for function declarations
Date: Tue, 24 Jun 2025 19:19:03 -0700	[thread overview]
Message-ID: <20250624191903.1dcfdf16@f41-zbm-amd> (raw)
In-Reply-To: <87frfpyy0k.fsf@tromey.com>

On Tue, 24 Jun 2025 09:12:11 -0600
Tom Tromey <tom@tromey.com> wrote:

> >>>>> "Kevin" == Kevin Buettner <kevinb@redhat.com> writes:  
> 
> Kevin> This commit was motivated by comments 3 and 4 for bug 31563:
> Kevin> https://sourceware.org/bugzilla/show_bug.cgi?id=31563#c3  
> 
> I didn't really read through this yet, but in general a patch to add a
> new (non-local) full symbol that doesn't have a corresponding change to
> the indexer seems like it will be incorrect.  The issue is that lookups
> will only work if the CU has already been expanded; and with my
> long-suffering search-via-the-index series, the lookups will fail
> entirely.

Do you think that a function declaration (where, in GDB's symbol table,
the address class is LOC_UNRESOLVED) should be added to the index?

These symbols don't have addresses associated with them, though the
address can be obtained from the minsyms.

One of the things that I had to do while looking at and fixing the
various regressions that I encountered was to make various parts of
gdb NOT use the function declaration symbols, or, at least prefer
other symbols over the ones for declarations. E.g. they had to be
removed in order for "info func" to continue working as before.

If you think it's needed, I'll take a look, but I'd guess that if
I add them for indexing purposes, other bits of code might have to
be adjusted to later remove them.

Kevin


  reply	other threads:[~2025-06-25  2:20 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-06-13  4:37 Kevin Buettner
2025-06-24 15:12 ` Tom Tromey
2025-06-25  2:19   ` Kevin Buettner [this message]
2025-06-25 17:17     ` Kevin Buettner

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=20250624191903.1dcfdf16@f41-zbm-amd \
    --to=kevinb@redhat.com \
    --cc=gdb-patches@sourceware.org \
    --cc=tom@tromey.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