Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Tom Tromey <tom@tromey.com>
To: Andrew Burgess <aburgess@redhat.com>
Cc: Simon Marchi <simark@simark.ca>,  Tom Tromey <tom@tromey.com>,
	gdb-patches@sourceware.org
Subject: Re: [PATCHv3] gdb: resolve class name via DW_AT_signature in cooked index
Date: Mon, 14 Sep 2026 09:36:25 -0600	[thread overview]
Message-ID: <87cxuf7sli.fsf@tromey.com> (raw)
In-Reply-To: <87ecewc6gn.fsf@redhat.com> (Andrew Burgess's message of "Mon, 14 Sep 2026 14:23:20 +0100")

>>> I would much prefer a new cooked_index_flag_enum value over allowing
>>> NULL pointers.
>> 
>> Why?  Just wondering.

Andrew> Also, in this case, the point is that we end up creating the
Andrew> cooked_index_entry before we know the name, so what value should the
Andrew> name pointer hold?

Andrew> So V3 switched to NULL pointers as something that is fairly obviously an
Andrew> "unset" string.

I won't complain.  I just think letting in NULL pointers often ends badly.

Andrew> then 'info complaints' would like each objfile and the number of
Andrew> complaints seen, and 'info complaints <objfile name>' would actually
Andrew> list the complaints for the given objfile.

This might be nicer, but consider that many of the existing complaints
are just somebody's opinion about the compiler output, and not only are
they not actionable, they will not ever be fixed.

My contention is that no complaint has actually ever been fixed by
virtue of being a complaint -- that is, maybe a compiler fix has been
done, but it's been a separate action, not driven by gdb's output.

Basically complaints are worthless.  I won't object if you work on this,
but IMNSHO putting any effort into this is a waste of time.

Tom

  parent reply	other threads:[~2026-09-14 15:36 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-19 10:03 [PATCH] [GDB 18] " Andrew Burgess
2026-08-21 17:07 ` Tom Tromey
2026-08-28 21:30 ` [PATCHv2] " Andrew Burgess
2026-09-01 13:31   ` [PATCHv3] " Andrew Burgess
2026-09-10 16:11     ` Simon Marchi
2026-09-11 19:18       ` Tom Tromey
2026-09-12  2:06         ` Simon Marchi
2026-09-14 13:23           ` Andrew Burgess
2026-09-14 14:57             ` Simon Marchi
2026-09-14 15:38               ` Tom Tromey
2026-09-15 10:25               ` Andrew Burgess
2026-09-15 15:01                 ` Tom Tromey
2026-09-15 15:55                   ` Simon Marchi
2026-09-15 17:21                     ` Simon Marchi
2026-09-14 15:36             ` Tom Tromey [this message]
2026-09-10 16:18     ` 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=87cxuf7sli.fsf@tromey.com \
    --to=tom@tromey.com \
    --cc=aburgess@redhat.com \
    --cc=gdb-patches@sourceware.org \
    --cc=simark@simark.ca \
    /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