Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Tom Tromey <tom@tromey.com>
To: dominikmascherbauer <dominik.mascherbauer@gmail.com>
Cc: gdb-patches@sourceware.org,
	 dominikmascherbauer <dominik.mascherbauer@oracle.com>
Subject: Re: [PATCH 0/3] DWARF type signature lookup fallback.
Date: Wed, 12 Mar 2025 10:32:45 -0600	[thread overview]
Message-ID: <87ldtaqkeq.fsf@tromey.com> (raw)
In-Reply-To: <cover.1741701275.git.dominik.mascherbauer@oracle.com> (dominikmascherbauer's message of "Tue, 11 Mar 2025 15:57:17 +0100")

>>>>> dominikmascherbauer  <dominik.mascherbauer@gmail.com> writes:

> I am working on a patch that adds parameters to allow type signature
> fallback for DWARF type units to fallback to other objfiles.  This
> allows to only create type units once and reuse them by their type
> signature, reducing duplication of type units.  It builds on the
> uniqueness of type signatures, so a type signature always references
> the same type unit.

I am not sure this can really work due to lifetime constraints.

GDB has some rules about type ownership:

1. Arch-owned types must only refer to other arch-owned types

2. Objfile-owned types must only refer to other types coming from the
   same objfile, or to arch-owned types

These rules exist so that if an objfile is removed, there will not be
any dangling pointers.

I think this series violates rule 2.

There's a follow-on rule to this that isn't as frequently discussed, but
a symbol in an objfile has to follow rule 2 as well: it can't refer to
types from another objfile.  And I think this series also violates this.

I think you can see this in action for opaque types, where the lookup is
done over and over, because caching the result would violate the rules.
(This brings up the question of why you want this feature at all as
opposed to just using opaque type resolution.)


Anyway, this can't be easily remedied.  One idea we have discussed in
the past is to have a "type GC".  What this would mean is removing type
ownership -- just allocate all types globally.  Then, have a garbage
collector that removes type objects when things change, for instance
after an objfile is destroyed.

This is difficult to implement though.  For one thing types can refer
back to symbols.  Though perhaps this particular special case could be
handled by the GC.

Maybe other approaches are possible too, I don't know.

Tom

  parent reply	other threads:[~2025-03-12 16:33 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-03-11 14:57 dominikmascherbauer
2025-03-11 14:57 ` [PATCH 1/3] Add new commands for controlling type signature fallback dominikmascherbauer
2025-03-11 17:33   ` Eli Zaretskii
2025-03-12  9:12     ` Dominik Mascherbauer
2025-03-12 14:38       ` Eli Zaretskii
2025-03-12 14:44         ` Dominik Mascherbauer
2025-03-11 14:57 ` [PATCH 2/3] Add type signature fallback and JIT objfile restriction dominikmascherbauer
2025-03-11 14:57 ` [PATCH 3/3] Add testing for type signature fallback dominikmascherbauer
2025-03-12 15:37 ` [PATCH v2 0/3] DWARF type signature lookup fallback dominikmascherbauer
2025-03-12 15:37   ` [PATCH v2 1/3] Add new commands for controlling type signature fallback dominikmascherbauer
2025-03-12 15:43     ` Eli Zaretskii
2025-03-12 15:37   ` [PATCH v2 2/3] Add type signature fallback and JIT objfile restriction dominikmascherbauer
2025-03-12 15:37   ` [PATCH v2 3/3] Add testing for type signature fallback dominikmascherbauer
2025-03-12 16:32 ` Tom Tromey [this message]
2025-03-13 10:42   ` [PATCH 0/3] DWARF type signature lookup fallback Dominik Mascherbauer
2025-03-13 15:37     ` 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=87ldtaqkeq.fsf@tromey.com \
    --to=tom@tromey.com \
    --cc=dominik.mascherbauer@gmail.com \
    --cc=dominik.mascherbauer@oracle.com \
    --cc=gdb-patches@sourceware.org \
    /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