From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from esa4.mentor.iphmx.com (esa4.mentor.iphmx.com [68.232.137.252]) by sourceware.org (Postfix) with ESMTPS id 2C0773857702 for ; Thu, 4 May 2023 10:31:00 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 2C0773857702 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=codesourcery.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=mentor.com X-IronPort-AV: E=Sophos;i="5.99,249,1677571200"; d="scan'208";a="4332325" Received: from orw-gwy-02-in.mentorg.com ([192.94.38.167]) by esa4.mentor.iphmx.com with ESMTP; 04 May 2023 02:30:54 -0800 IronPort-SDR: 2Euf14zMibtAoc53PfvtKtuoUhu4UCeF4gw04ChkNoNlXbiV/Maqz3s1GjrP7yhCM1rITKpDTz Mwi/YfM70ihdvFG/mXAVMyWthkTD/tiaZ3aMBf6TeqcV2S4K++6IGTfgFwCtYavrbdEZUNMEzD gg9iAMyqKRjexqr3C7WKxBvMaN24FjxrpD30Irj4j9ml/GfcAu6ISJQg+IPoWaJ/E9uwrb7zB2 ge/nP0C4ujob78H85CzksRJF+6Pp+AC1CqfWAKbMdtj5uN6zP9EevQYJ72ohTVpfBcpAa8Ihmz wkU= Message-ID: <0f441079-0fe3-3c25-f983-627f56406b1c@codesourcery.com> Date: Thu, 4 May 2023 12:30:49 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.10.1 Subject: Re: [RFC,patch] Linker plugin - extend API for offloading corner case (aka: LDPT_REGISTER_CLAIM_FILE_HOOK_V2 linker plugin hook [GCC PR109128]) Content-Language: en-US From: Tobias Burnus To: Binutils , gcc-patches , Richard Biener CC: Joseph Myers References: <3cdc56a8-62eb-d33c-3038-0af00d8a52ba@codesourcery.com> In-Reply-To: <3cdc56a8-62eb-d33c-3038-0af00d8a52ba@codesourcery.com> Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: quoted-printable X-Originating-IP: [137.202.0.90] X-ClientProxiedBy: svr-ies-mbx-14.mgc.mentorg.com (139.181.222.14) To svr-ies-mbx-12.mgc.mentorg.com (139.181.222.12) X-Spam-Status: No, score=-7.5 required=5.0 tests=BAYES_00,HEADER_FROM_DIFFERENT_DOMAINS,KAM_DMARC_STATUS,KAM_SHORT,NICE_REPLY_A,SPF_HELO_PASS,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: Based on the the discussion with Richard B. on #gcc, some more details why = the linker does (and might want) to call the plugin for files it does not need: For LTO with no-fat binaries, a symbol in a static library might still be n= eeded but the linker does not know as the file might only contain LTO objects. The linker then c= alls: bfd_link_plugin_object_p -> ld_plugin_object_p which calls in case of GCC's lto-plugin: claim_file_handler * The latter file checks for LTO symbols and, if found, sets *claimed =3D t= rue and registers the found symbols via add_symbols =E2=86=92 The linker than ignores all other symbols and only uses the plugi= n-provided symbols. * When all files have been processed, the linker calls all_symbols_read_handler and the lto-plugin can ask (get_symbols) whethe= r a given symbol was used. For the offload usage, the problem is: * The code currently assumes that a file is used when 'claim_file_handler' = is invoked by the linker =E2=86=92 It cannot claim the file itself as then symbols in the file are i= gnored by the linker. =E2=86=92 Thus, if the file contains host-side LTO and is *claimed =3D true= , it is fine. Likewise, if symbols in the file cause the linker itself to use the file= , it is fine. However, if neither the plugin claims the file nor the file is linked vi= a the linker, there is a problem (=E2=86=92 mismatch between host and device side). Inside the all_symbols_read_handler, GCC's lto-plugin.cc could remove a fil= e from the to-be-used for device-side lto-wrapper list, but there is no way to ask the= linker if a given file is will be linked/is used or not. (Only per-symbol enquiringly= for LTO exists.) The additional flag now permits for the offload use to ignore the file if t= he linker has no use for it (and passes it only for non-fat symbols host-side LTO check t= o the linker); thus, we can then ignore the file for offloading purpose, unless it is used= for LTO - but that's something the plugin knows itself. Note: That's really only an issue about whether a file (from a static libra= ry) is used and not whether a certain symbol is used. For the host side, the function-p= ointer table is constructed by section merging and the device side also forces the outpu= t of the table. But all output forcing/keep-symbol handling fails if the whole file is drop= ped on one side (linker for the host side) but not on the other (linker plugin for the non-= host offload side). I hope this clarifies the problem, background and solution a bit better. Tobias On 02.05.23 19:19, Tobias Burnus wrote: > See also https://gcc.gnu.org/PR109128 (+ description in the patch log) > > The linker plugin API was designed to handle LTO - such that the > compiler (i.e. GCC's lto-plugin) > can claim an input file if it finds LTO code. In that case, the > symbols inside that file are ignored > by 'ld'. > > However, GCC also uses the LTO for offloading: code designated for > running on a non-host device > (GPUs) is saved in a special section in LTO format. This code then > ends up being compiled for > offloading but otherwise not the file is not claimed, keeping the > symbols for 'ld' to process, > unless that file is also uses real, host-side LTO. > > This mostly works okay, but a corner case exists (see PR for an > example) where 'ld' calls the > GCC's lto-plugin but does not actually use the symbols of that file. > That's fine, in principle, > but if that file contains offloading code, there is a problem: To > match host and device functions, > a table is created on both sides, but that table obviously must match. > However, when lto-plugin's > offload code processes those while ld does not link them, it fails. > > It turned out (kudos to Joseph for debugging + writing the patches) > that in that case ld.bfd does > not actually regards that file as being used but just offers it to > llto-plugin in case it needs > symbols from it. > > To get this working, the current API is insufficient. > > Possible solutions: > * Tell lto-plugin whether 'ld' actually needs symbols from a file or > it just offers the file > in case that lto-plugin wants to claim that file > =3D> That's implemented in the attached patch. > * Make it possible to "claim" a file without discarding the ld-visible > symbols > * Asking the linker later whether the file/some symbols are actually > used. > * something else ... > > > What this patch does: > * It adds a new API callback (LDPT_REGISTER_CLAIM_FILE_HOOK_V2) that > takes an additional > boolean argument which states whether ld.bdf intens to use that > file/symbols from that > file or whether it just asks the plugin in case it wants to claim it. > * On the ld.bfd side, it wires this up. > * On the GCC lto-plugin side, it uses that API is available, otherwise > it uses the existing API. > > The way the linker plugin handling is written, it works fine at > runtime if only one side > supports the new hook. (Except, of course, that for fixing the issue > both need to support it.) > > Regarding those patches: Are they ok for mainline? Any comment, better > approach, suggestion? > > Tobias > > PS: Attached is the Binutils' ld side of the patch and the GCC > lto-plugin side of the patch set. > ----------------- > Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstra=C3=9Fe > 201, 80634 M=C3=BCnchen; Gesellschaft mit beschr=C3=A4nkter Haftung; > Gesch=C3=A4ftsf=C3=BChrer: Thomas Heurung, Frank Th=C3=BCrauf; Sitz der G= esellschaft: > M=C3=BCnchen; Registergericht M=C3=BCnchen, HRB 106955 ----------------- Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstra=C3=9Fe 201= , 80634 M=C3=BCnchen; Gesellschaft mit beschr=C3=A4nkter Haftung; Gesch=C3= =A4ftsf=C3=BChrer: Thomas Heurung, Frank Th=C3=BCrauf; Sitz der Gesellschaf= t: M=C3=BCnchen; Registergericht M=C3=BCnchen, HRB 106955