From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by sourceware.org (Postfix) with ESMTPS id 3C99D3858C98 for ; Wed, 28 Feb 2024 08:54:04 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 3C99D3858C98 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 3C99D3858C98 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=170.10.133.124 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1709110445; cv=none; b=KWJp8PfsGgC/3MRbl+1yH/3IvT+ZdSD2y2tXay7onuGGP0meADP0nx+bk+O7tKdZcDX5MeuAyTiMd+1zIus78MoJKv+m5NBNRAfvOzg/tjPudoQ705oONcAdANYxje1f6MF5uGG3yvhWcuKnoS+yEd5uB7KJIrGn4bz51nzdvpQ= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1709110445; c=relaxed/simple; bh=F7cdO7Xv4N4iNOUNqi4NHnEKNBQY3kwKKKfJHglmbUg=; h=DKIM-Signature:Date:From:To:Subject:Message-ID:MIME-Version; b=VJ8+yeC80WFth3zPGy8VZSaIyDi6Qum/tEQqnQLdrkAg+7VOcF8INOXxEu7pkwG9tb6kD3ArL3WOfrVOeHYww44rWEbc/+n+rjk100k3bUvB9CSgncGmdbexvIYYbh+FGwqyyzV/F6vZShHSsBvkMCqpPnbeLn0XB4q3bPJLWpU= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1709110443; h=from:from:reply-to:reply-to:subject:subject: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=AH8Uw48utOylrgghpV4Nq/Z7nL+mygRoD0Rz1lHMboM=; b=SJWyLAnw3t43Gay0IkU7Yl/ZZHYZc7lBSfwlQIaqOqvt/vv7CmCQhe4sDstb2Kf5cNDhxg fGuK9daTvO0HzgmG8Rur3yU7rZzrpLNlOfrQ9k0xxD6qkCoAF8bEDfi+GprUjazdKU/Nil dGnCI5DlZScsURNczEi09DUDKDIp1OI= Received: from mimecast-mx02.redhat.com (mx-ext.redhat.com [66.187.233.73]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-222-lcq0d2jaMsilTxo3Z0fRoQ-1; Wed, 28 Feb 2024 03:54:02 -0500 X-MC-Unique: lcq0d2jaMsilTxo3Z0fRoQ-1 Received: from smtp.corp.redhat.com (int-mx07.intmail.prod.int.rdu2.redhat.com [10.11.54.7]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 7D5F338212DB; Wed, 28 Feb 2024 08:54:01 +0000 (UTC) Received: from tucnak.zalov.cz (unknown [10.39.192.25]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 3FA431C060AF; Wed, 28 Feb 2024 08:54:01 +0000 (UTC) Received: from tucnak.zalov.cz (localhost [127.0.0.1]) by tucnak.zalov.cz (8.17.1/8.17.1) with ESMTPS id 41S8rwAE2997749 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Wed, 28 Feb 2024 09:53:58 +0100 Received: (from jakub@localhost) by tucnak.zalov.cz (8.17.1/8.17.1/Submit) id 41S8rvPx2997748; Wed, 28 Feb 2024 09:53:57 +0100 Date: Wed, 28 Feb 2024 09:53:57 +0100 From: Jakub Jelinek To: Richard Biener , Uros Bizjak , hjl.tools@gmail.com, Hongtao Liu , Jan Hubicka Cc: gcc-patches@gcc.gnu.org Subject: Re: [PATCH] i386: Guard noreturn no-callee-saved-registers optimization with -mnoreturn-no-callee-saved-registers [PR38534] Message-ID: Reply-To: Jakub Jelinek References: MIME-Version: 1.0 In-Reply-To: X-Scanned-By: MIMEDefang 3.4.1 on 10.11.54.7 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Spam-Status: No, score=-3.7 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,KAM_SHORT,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H4,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE,SPF_NONE,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: Hi! Adding Hongtao and Honza into the loop as the ones who acked the original patch. The no_callee_saved_registers by default for noreturn functions change can break in-process backtrace(3) or backtraces from debugger or other process (quite often, any time the noreturn function decides to use the bp register and any of the parent frames uses a frame pointer; the unwinder just crashes in the libgcc unwinder case, gdb prints stack corrupted message), so I'd like to save bp register in that case: https://gcc.gnu.org/pipermail/gcc-patches/2024-February/646591.html and additionally the no_callee_saved_registers by default for noreturn functions change can make debugging harder, again not localized to the noreturn function, but any of its callers. So, if say glibc abort function implementation needs a lot of normally callee-saved registers, no matter how users recompile their apps, they will see garbage or optimized out vars/parameters in their code unless they rebuild their glibc with -O0. So, I think we should guard that by a non-default option: https://gcc.gnu.org/pipermail/gcc-patches/2024-February/646649.html Plus we need to somehow make sure to emit DW_CFA_undefined for the modified but not saved normally callee-saved registers, so that we at least don't get garbage in debug info. H.J. posted some patches for that, so far I wasn't happy about the implementation but the actual change is desirable. Your thoughts on this? Jakub