From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp-out1.suse.de (smtp-out1.suse.de [IPv6:2001:67c:2178:6::1c]) by sourceware.org (Postfix) with ESMTPS id A10EE3858D28 for ; Wed, 18 Jan 2023 14:03:43 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org A10EE3858D28 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=suse.de Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=suse.de Received: from relay2.suse.de (relay2.suse.de [149.44.160.134]) by smtp-out1.suse.de (Postfix) with ESMTP id 9461A3EBEC; Wed, 18 Jan 2023 14:03:42 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1674050622; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=zH8OcR/RtzQdX+UNv62/uLYKgfTxrfXPy47faftwfmM=; b=IpVA4wF2HJNXwWbRlRPUeEH5FVE/feMJXzVkwYeal/URJZRMH/z18OaI3gYksQ3sTdqUfX EZjWWQUQQPgJdYMumLizje4dkHRJavrS3Mr/siZI/fkIaL/+pN/1lHagLa10NVbhSu3/vQ Wn/JAyNvhR3iKW79v/LJFu74SdD1res= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1674050622; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=zH8OcR/RtzQdX+UNv62/uLYKgfTxrfXPy47faftwfmM=; b=eH3/BYxZTVAFzq1kbr4eWvIlODrXSCQpkLglLVWNOsYggsVcKrW337uwy8/7ctXDL/Ph9o XaItUxRnCjAzR7DQ== Received: from wotan.suse.de (wotan.suse.de [10.160.0.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by relay2.suse.de (Postfix) with ESMTPS id 8C9D22C142; Wed, 18 Jan 2023 14:03:42 +0000 (UTC) Received: by wotan.suse.de (Postfix, from userid 10510) id 6DB4E64A3; Wed, 18 Jan 2023 14:03:42 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by wotan.suse.de (Postfix) with ESMTP id 6C6A06393; Wed, 18 Jan 2023 14:03:42 +0000 (UTC) Date: Wed, 18 Jan 2023 14:03:42 +0000 (UTC) From: Michael Matz To: gcc-patches@gcc.gnu.org cc: Jakub Jelinek , Andreas Schwab , Richard Biener , Jan Hubicka Subject: Re: [PATCH] lto: pass through -funwind-tables and -fasynchronous-unwind-tables In-Reply-To: Message-ID: References: User-Agent: Alpine 2.20 (LSU 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Spam-Status: No, score=-3.1 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,SPF_HELO_NONE,SPF_PASS,TXREP 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 Wed, 18 Jan 2023, Andreas Schwab via Gcc-patches wrote: > No unwind tables are generated, as if -funwind-tables is ignored. If > LTO is disabled, everything works as expected. On Risc-V btw. (which, unlike i386,aarch64,s390,rs6000 does not effectively enable funwind-tables always via either backend or common/config/$arch/ code, which is the reason why the problem can't be seen there). It's an interaction with -g : The problem (with cross compiler here, but shouldn't matter): % riscv64-gcc -g -flto -funwind-tables -fPIC -c hello.c % riscv64-gcc -shared hello.o % readelf -wF a.out ... empty .eh_frame ... Contents of the .debug_frame section: ... content ... Using a compiler for any of the above archs makes this work (working means that the unwind info is placed into .eh_frame, _not_ into .debug_frame). Not using -g makes it work. Adding -funwind-tables to the link command makes it work. Adding -fexceptions to the compile command makes it work. Not using LTO makes it work. So, it's quite clear that the option merging algorithm related to all this is somewhat broken, the global (or per function, or whatever) -funwind-tables option from hello.o doesn't make it correctly into the output (when -g is there). Adding -fexception makes it work because then the functions will have personalities and on LTO-read-in _that_ will implicitely enable funwind-tables again (which should have been enabled already by the option-read-in). As written initially the other archs are working because they all have various ways of essentially setting flag_unwind_tables always: i386 via common/config/i386/i386-common.cc opts->x_flag_asynchronous_unwind_tables = 2; config/i386/i386-options.cc if (opts->x_flag_asynchronous_unwind_tables == 2) opts->x_flag_unwind_tables = opts->x_flag_asynchronous_unwind_tables = 1; rs6000 via common/config/rs6000/rs6000-common.cc #ifdef OBJECT_FORMAT_ELF opts->x_flag_asynchronous_unwind_tables = 1; #endif (which ultimately also enabled flag_unwind_tables) s390 via common/config/s390/s390-common.cc opts->x_flag_asynchronous_unwind_tables = 1; aarch64 via common/config/aarch64/aarch64-common.cc #if (TARGET_DEFAULT_ASYNC_UNWIND_TABLES == 1) { OPT_LEVELS_ALL, OPT_fasynchronous_unwind_tables, NULL, 1 }, { OPT_LEVELS_ALL, OPT_funwind_tables, NULL, 1}, #endif (the #define here is set for aarch64*-*-linux* ) So the problem cannot be readily demonstrated on these architectures. risc-v has no such code (and doesn't need to). Ciao, Michael.