From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pf1-x42d.google.com (mail-pf1-x42d.google.com [IPv6:2607:f8b0:4864:20::42d]) by sourceware.org (Postfix) with ESMTPS id 07CBF3858C20 for ; Thu, 11 May 2023 00:40:54 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 07CBF3858C20 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-pf1-x42d.google.com with SMTP id d2e1a72fcca58-643990c5373so7958882b3a.1 for ; Wed, 10 May 2023 17:40:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1683765653; x=1686357653; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=FecT6Uu6F8k4OYm0lDwoRLu7J8IsfDz8wZW7MWpoINM=; b=mKTCJdzafbOzoJTy8epFnuUjKlDBc7/GFjdbDNJTcEQlUJruygf44I/2GHidUhT+lc UO6tHTms4SrPnjd+nGuTXbE8xZLl1P7oRzhrJ/Pjz9NWYL+CenZmTDKWk/fH+6igDIyi AlMoz/vJ3kjKam+Q+IJD2FjD46ET0FXpy/VfsoVWQH3boFynrkgsqo6eRZFawNJOo6uG D+SZtSto8Y+r1jvhT0aiB7s+a6E3IbmRx2+xGSaUqXHBBMv7SETDfdFeMbHLbhfjTJRQ JzXzDrtdrgVUBYBhw3Xf48/kFqXwHDcduF01HsRRkXyoV67CAbm3PwiWpnPVLQwgXioQ t00Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1683765653; x=1686357653; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=FecT6Uu6F8k4OYm0lDwoRLu7J8IsfDz8wZW7MWpoINM=; b=EsPH9AABY5FjARf4415H4EqiQi/eYymCBy1fkYmovZDcRMXCz6RuBM+a8jo0AJzmFz HFh7ED7ei3mLtgdNt9kK7Hjfjq6brb+coh5T8OWMtrPIPku6l4mDpkmwa3FM/UybUHiN a0nARTww918tzOmawVULvCnn0iG5+ZjfOMyQRHORW2U+sde3EnxjIN9+fnMGvWg6+Rqn uVU9vBmjzosbRD/IonUNGPk64JHSPI4a+GwuZke7/qaOErss5eWKcYHte7sv1Dyko6CN KjP89BtXI+0hM9W0dVvz8gxhSWjBBzJtguveqeCMYzzjlByb1KNNIZwr20Na/6wBfM0i ADIg== X-Gm-Message-State: AC+VfDyLz5ob+x6UxfMFSXQpMudBnCqPmbF2SueT+UaE1BUrL8ksFrdG n1YrPz0zeLlziYj8bcNImyQ6uFeFfgU= X-Google-Smtp-Source: ACHHUZ4japGzPLXkSaX85fiDVPkDhyqy9xBxUiF+or5R/pHccTLs/fnYrwjQrvLKRt6DL6ucfVDpDw== X-Received: by 2002:a05:6a00:1396:b0:646:6cc3:4a52 with SMTP id t22-20020a056a00139600b006466cc34a52mr14388601pfg.3.1683765652943; Wed, 10 May 2023 17:40:52 -0700 (PDT) Received: from squeak.grove.modra.org ([2406:3400:51d:8cc0:ba5d:eb3b:1727:7e2c]) by smtp.gmail.com with ESMTPSA id j10-20020a62e90a000000b0063f16daf7dbsm4049396pfh.55.2023.05.10.17.40.51 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 10 May 2023 17:40:52 -0700 (PDT) Received: by squeak.grove.modra.org (Postfix, from userid 1000) id DB2BB1142EC0; Thu, 11 May 2023 10:10:49 +0930 (ACST) Date: Thu, 11 May 2023 10:10:49 +0930 From: Alan Modra To: Richard Biener Cc: Tobias Burnus , Binutils , gcc-patches , Joseph Myers Subject: Re: [RFC,patch] Linker plugin - extend API for offloading corner case (aka: LDPT_REGISTER_CLAIM_FILE_HOOK_V2 linker plugin hook [GCC PR109128]) Message-ID: References: <3cdc56a8-62eb-d33c-3038-0af00d8a52ba@codesourcery.com> <0f441079-0fe3-3c25-f983-627f56406b1c@codesourcery.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Spam-Status: No, score=-3026.9 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On Thu, May 04, 2023 at 11:02:25AM +0000, Richard Biener via Binutils wrote: > So since we expect the linker to use the host side table is there a way > for the plugin to exactly query that (the set of symbols the linker > uses from the object passed to the plugin)? That would be possible and relatively easy to implement, but might be slow. > Because if the linker > uses something from the file but _not_ the host side offload table > (-ffunction-sections -fdata-sections) then things would still go > wrong, right? > Is there a way to connect both in a way that the linker discards > either if the other isn't present? No, or at least I do not want to even think about implementing such a linker "feature". The problem is that after you have modified the global linker symbol table after adding an object's symbols, it is virtually impossible to restore the state of symbols to what they would be without that object. (Yes, we do that sort of thing for as-needed shared libraries, but the restoration happens immediately after adding the symbols. I also regret implementing it the way I did.) The patch posted is OK from the linker side of things. -- Alan Modra Australia Development Lab, IBM