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 1A4E23858CDB for ; Thu, 4 May 2023 13:25:37 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 1A4E23858CDB 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="4348963" Received: from orw-gwy-02-in.mentorg.com ([192.94.38.167]) by esa4.mentor.iphmx.com with ESMTP; 04 May 2023 05:25:30 -0800 IronPort-SDR: 0mpXk6+cyjzTo2P7sk77c2+GZ7VEgdYiUKdWtSndCkkFHRG+xqMETRcnMrrZuitnIL3x3pYFJa 7J7YHmCTleHMxgEcoYsdobRFGhJjavZSoSfK2bsxPvuVRy2znTlFuACNhqz4x1XJ/oH46YIFdP dn2qqo4h+7wulhBspj4sli1PeQAEpiAcvlaIr585tDTp1m9H/Hzhhr4Tkr5ObtV0OwNQnmRDA/ 6UQ5pWpSjoEu1EjVOmhnHfvcpktuzHikYrt3AxI32yHwAB8a0Uycd7IL4eBx3slCRBPtTGKcsM OCU= Message-ID: Date: Thu, 4 May 2023 15:25:24 +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 To: Richard Biener CC: Binutils , gcc-patches , Joseph Myers References: <3cdc56a8-62eb-d33c-3038-0af00d8a52ba@codesourcery.com> <0f441079-0fe3-3c25-f983-627f56406b1c@codesourcery.com> From: Tobias Burnus In-Reply-To: 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-15.mgc.mentorg.com (139.181.222.15) 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,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: On 04.05.23 13:02, Richard Biener wrote: > So since we expect the linker to use the host side table is there a way > for the plugin to exactly query that Background - feel free to skip to the next quote / reply bit. The following is what we have for the host side: We have (=E2=86=92 libgcc/offloadstuff.c) #define OFFLOAD_FUNC_TABLE_SECTION_NAME ".gnu.offload_funcs" * crtoffloadbegin.a with: const void *const __offload_func_table[0] __attribute__ ((__used__, visibility ("hidden"), section (OFFLOAD_FUNC_TABLE_SECTION_NAME))) =3D { }; * crtoffloadend.a with: const void *const __offload_funcs_end[0] __attribute__ ((__used__, visibility ("hidden"), section (OFFLOAD_FUNC_TABLE_SECTION_NAME))) =3D { }; * crtoffloadtable.a with: const void *const __OFFLOAD_TABLE__[] __attribute__ ((__visibility__ ("hidden"))) =3D { &__offload_func_table, &__offload_funcs_end, Each TU generates an a static array with constructor in that section =E2=80=93 and the values for the constructor are the function (or variable) addresses, i.e. omp_finish_file has: tree funcs_decl =3D build_decl (UNKNOWN_LOCATION, VAR_DECL, get_identifier (".offload_func_table")= , funcs_decl_type); set_decl_section_name (funcs_decl, OFFLOAD_FUNC_TABLE_SECTION_NAME); > (the set of symbols the linker > uses from the object passed to the plugin)? 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? Shouldn't this only affect where the functions/variables themselves are placed to - and not the section in which the two offload-funs/-vars arrays are placed to, given that it was explicitly set? At least that's how I understand the GCC documentation and after glancing at the varasm.c code. That matches also what I see when using those flags. There are differences related to, e.g. .text.s1.0._omp_fn.0 but .offload_var_table and .offload_func_table still look fine. (Side remark, I am wondering whether we should use "retain" for everything that goes into the special sections, i.e. whether the following should be a= dded: +#ifndef ACCEL_COMPILER + if (SUPPORTS_SHF_GNU_RETAIN) + { + DECL_ATTRIBUTES (funcs_decl) =3D tree_cons (get_identifier ("reta= in"), + NULL_TREE, NULL_TREE); to omp-offload.c (+ "retain" as __attribute__ in libgcc/offloadstuff.c)? > Is there a way to connect both in a way that the linker discards > either if the other isn't present? I think as soon as the file is used, they are present, at least with 'retai= n', even though they might be size-zero arrays. My attempts to check with get_symbols{_v2,_v3} failed. If I recall correctl= y, the way everything it setup for the hash, which includes also the file name= , makes it hard to query something which has not been added by get_symbols. Even if we added a new interface, implementing it in a generic way and bein= g compatible with the ld.bfd way of storing symbols as hash might be a bit co= mplex. Tobias ----------------- 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