From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id jJiTOcq20meeIQ4AWB0awg (envelope-from ) for ; Thu, 13 Mar 2025 06:43:22 -0400 Authentication-Results: simark.ca; dkim=pass (2048-bit key; unprotected) header.d=gmail.com header.i=@gmail.com header.a=rsa-sha256 header.s=20230601 header.b=g2ZuJOW+; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id DC7F41E105; Thu, 13 Mar 2025 06:43:22 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 4.0.0 (2022-12-13) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-5.4 required=5.0 tests=ARC_SIGNED,ARC_VALID,BAYES_00, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED autolearn=ham autolearn_force=no version=4.0.0 Received: from server2.sourceware.org (server2.sourceware.org [8.43.85.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id 5635F1E08E for ; Thu, 13 Mar 2025 06:43:22 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 062793858414 for ; Thu, 13 Mar 2025 10:43:22 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 062793858414 Authentication-Results: sourceware.org; dkim=pass (2048-bit key, unprotected) header.d=gmail.com header.i=@gmail.com header.a=rsa-sha256 header.s=20230601 header.b=g2ZuJOW+ Received: from mail-ej1-x634.google.com (mail-ej1-x634.google.com [IPv6:2a00:1450:4864:20::634]) by sourceware.org (Postfix) with ESMTPS id 519CB3858D33 for ; Thu, 13 Mar 2025 10:42:29 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 519CB3858D33 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 519CB3858D33 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=2a00:1450:4864:20::634 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1741862549; cv=none; b=EwjrKjSqXRSjAyfI8icRUbMGAfvYA4b2dTRQSO/DWiEAdCNb2gYbn70NIy90X2VWaFAFIpd6Zktej64P2ZaZ+TWRNj+8C7PCQRfpL+Q2II14hDx6QUQudzd4Zk44Cp0a1Ip4h3wTJ0nDEPUR0XKixxDTPevQEJ9RPBwUrJQkQ0w= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1741862549; c=relaxed/simple; bh=VBhuDT8FOKOHGbCA/pQyH4ZSiBP48O5YzI7imMl0jIc=; h=DKIM-Signature:Message-ID:Date:MIME-Version:Subject:To:From; b=ROjNe0uLHx8uo4QlrIlKnKJ0qgp0geSouIcYV0SVe775jTMovnTgh7KtaZ/N4/Pn1H07XR+5beKWni7bAkgGuPEHf6CqS7QsouDIpfi96PfDvFZM3qWJU2CoKGogLJ54Z0p+sSgME4MXgyd+NCnmKhwYtCriPbjJqn1AKeFBktU= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 519CB3858D33 Received: by mail-ej1-x634.google.com with SMTP id a640c23a62f3a-ac25520a289so147852266b.3 for ; Thu, 13 Mar 2025 03:42:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1741862548; x=1742467348; darn=sourceware.org; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=QLvCopYRHOBaEQicGQBzvTkbHm1/nRyfE7O7AVqRS1s=; b=g2ZuJOW+oPoErmfmVwOvEE9S/Y0XJnqdRI6vW+19axhxD8Uj0OX8Y22RAYxhRjagfF D8lmvD/5SZnXO1ajErKxPuUebV65Na8sep+0M7q+xp8jplIlQq5BiMaWjk+dx6j+tKGc Hc4POynTGQoKMba+W4bP//upor2VOlR1I1tSDODJOEvWNvQ1DN2CVEwvRu6u82967lqF pfvOiHw4RRMdtZTUAW/DdEXECviQbYTnPUSyY0Li+jPrPKzQvF+QF+Qu+9XTbQ7KZE9C dHJ7XIW6mlEJhbLh6crDzqi3fRNvsogDVwWHbwo1dyYE8+8i70khWXNRTxcKGhr4PK4M calg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1741862548; x=1742467348; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=QLvCopYRHOBaEQicGQBzvTkbHm1/nRyfE7O7AVqRS1s=; b=q++DtGukfLnXjxqb3FBozQh1bFHO9F0nfbV2Xl/GaKaChkvafqMN1cfBc3QyShU8JE nYBDOOoITKEtKPYdYRLJfuWUN7TvQq2QdFGVH3Y8oYyqQZFF66AsTTQcLtuniumgQB1y +Vp3RtBjUQ/Dc5idAivSBrnundjMqx3g0XBlQASSURRlJepTwezFaee9zDrDC+x8wsK4 uBpUr5udDpA0lK6Fy3zosRoFae2g1/7ug0x13M3NQ6wEjip5H1LjUwQ0usdrpeR/JeM4 8IZVgYFD4SC9xqrHguEnWKJqX1jlUHlylGCPg+R9iRJz7NBcsZzgaIiyHgI5UxQ8+yu8 xksg== X-Gm-Message-State: AOJu0YxfoGvkax5vdNEIMP0899v/CZiaAeX2uDYwMGCXHSdd8y8Xxc3d 48rtFsnZ5kQmSITmRjZJMwBpvnaeRc3cgCGdlPi926Meb9z6WHAH3E/sWFTmivM= X-Gm-Gg: ASbGncv8aT32zZNY19CPTLYe6uSieV3Z6M6BePM5KQ/Gd78Oh9E6qNW5o9EkdN8AYQF Dzn6DyARzhIv+dt8xdYLAcS84qQbfINDiHbl2kSEHzTmXi++MR6iSdEIm7uKRQj2wGgC5WHlSFp 1J+u6WY6nykBWP5jCdttFOHAqsuuI5qKqws1yA74LYwJUG3P355szSF97htKLsub6pr0x/uQ5CZ jITxLFRlVdG47IGobNdcBpIff8YRhexvuamU6S518c/75PBN0cumPoBWIc5dYnItGfgRmcUprW/ MdQukuIgy2ZnaPNSNX9LaMgRuyrYqEISUfUoxJ5UhEmRXqxs04WcuMLrLAMlDcFLIw== X-Google-Smtp-Source: AGHT+IGqsoqNGYIQvbzpO/iiLoDkIhpNo4G7pxOUALCW2SypqW52SrZYHadiS8xaCzC58uzStglQCg== X-Received: by 2002:a17:907:970d:b0:ac2:b9c8:b7ba with SMTP id a640c23a62f3a-ac2b9c8b83cmr1608939466b.10.1741862547564; Thu, 13 Mar 2025 03:42:27 -0700 (PDT) Received: from [140.78.145.182] ([140.78.145.182]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-ac3149cf133sm65324166b.106.2025.03.13.03.42.26 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 13 Mar 2025 03:42:27 -0700 (PDT) Message-ID: Date: Thu, 13 Mar 2025 11:42:26 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 0/3] DWARF type signature lookup fallback. To: Tom Tromey Cc: gdb-patches@sourceware.org, dominikmascherbauer References: <87ldtaqkeq.fsf@tromey.com> Content-Language: en-US From: Dominik Mascherbauer In-Reply-To: <87ldtaqkeq.fsf@tromey.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.30 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: gdb-patches-bounces~public-inbox=simark.ca@sourceware.org >>>>>> dominikmascherbauer 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 Thanks for the response. I agree that this series violates rule 2 as you mentioned. I was not aware of those rules at the time of implementing this patch. Thank you very much for pointing out opaque types. I did not come across those when trying to figure out how to reference existing types from other objfiles. For checking available options I mainly used the DWARF specification which does not mention them. My initial idea was to use type signatures as they should be unique even across multiple objfiles. Based on that I thought it would be possible to use type signatures for finding type units in other not linked objfiles such as objfiles coming from the JIT compilation interface. I tested opaque types for my use-case, and it did work out. So, I guess the best option for me is to adapt the generated debug info for opaque types. Thanks again, Dominik