From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx2.suse.de (mx2.suse.de [195.135.220.15]) by sourceware.org (Postfix) with ESMTPS id 3EB693857C43 for ; Thu, 24 Sep 2020 07:03:22 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 3EB693857C43 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=suse.de Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=rguenther@suse.de X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id ED204B20F; Thu, 24 Sep 2020 07:03:58 +0000 (UTC) Date: Thu, 24 Sep 2020 09:03:20 +0200 (CEST) From: Richard Biener Sender: rguenther@c653.arch.suse.de To: Tobias Burnus cc: gcc-patches , Jakub Jelinek , Jan Hubicka Subject: Re: [Patch] LTO: Force externally_visible for offload_vars/funcs (PR97179) In-Reply-To: Message-ID: References: <4250958d-f7bf-1a0a-31d2-63eff191b258@codesourcery.com> <0e22d8c5-1008-cad4-c131-57ee3950a73a@codesourcery.com> <26b07ad0-ba42-b2c6-2325-cad7360f8e2c@codesourcery.com> User-Agent: Alpine 2.21 (LSU 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Spam-Status: No, score=-5.0 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS, RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Sep 2020 07:03:23 -0000 On Wed, 23 Sep 2020, Tobias Burnus wrote: > Actually working patch attached. > > As mentioned, just using TREE_PUBLIC in input_offload_tables > works for functions but for variables this gets overridden. > > The externally_visible is set to avoid running into the > promote_symbol code (? visibility hidden) later in the > function. Hmm, but offload_vars and offload_funcs do not need to be exported since they get stored into tables with addresses pointing to them (and that table is exported). So I think we don't yet understand what goes wrong. Note that ultimatively the desired visibility is determined by the linker and communicated via the resolution file to the WPA stage. I'm not sure whether both host and offload code participate in the same link and thus if the offload tables are properly seen as being referenced (for a non-DSO symbols are usually _not_ force-exported) - so, how is the offload table constructed? I'm not sure we can properly tell the linker of the host object that a certain symbol will be referenced from a dynamically loaded DSO - visibility("default") doesn't work. #include int global_sym __attribute__((visibility("default"))); int main() { dlopen("test.so", RTLD_NOW); return 0; } with -flto we elide global_sym, if I compile with -Wl,-export-dynamic it works fine (even w/o the visibility). But the question is how to selectively mark a symbol at the compile-stage so the linker will force-export it ... The 'used' attribute seems to work but that feels like a band-aid ... Richard. > On 9/23/20 5:47 PM, Tobias Burnus wrote: > > ... > > On 9/23/20 4:23 PM, Tobias Burnus wrote: > >> On 9/23/20 3:10 PM, Richard Biener wrote: > >> > >>> On Wed, 23 Sep 2020, Richard Biener wrote: > >>>> LTRANS usually makes the symbols hidden, not local. > >> Could also be ? whatever the 'nm' output means. > >>>> So are you > >>>> sure this isn't a target bug (hidden symbols not implemented > >>>> but the host compiler obviously having checked that but assuming > >>>> the target behaves the same as the host) or a linker bug? > >> > >> Unlikely, I assume the Linux x86-64 linker is rather well tested. > >> As written this is the host ? just the offloading symbol table is > >> device specific. > >> > >>> See lto/lto-partition.c:promote_symbol btw. > >> > >> Thanks for the pointer; it pointed me to node->externally_visible, > > ... > > Tobias > > ----------------- > Mentor Graphics (Deutschland) GmbH, Arnulfstra?e 201, 80634 M?nchen / Germany > Registergericht M?nchen HRB 106955, Gesch?ftsf?hrer: Thomas Heurung, Alexander > Walter > -- Richard Biener SUSE Software Solutions Germany GmbH, Maxfeldstrasse 5, 90409 Nuernberg, Germany; GF: Felix Imend