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.129.124]) by sourceware.org (Postfix) with ESMTPS id C4ACA3858427 for ; Tue, 27 Feb 2024 09:56:06 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org C4ACA3858427 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 C4ACA3858427 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=170.10.129.124 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1709027768; cv=none; b=A1tGXq3OUBW/AfMnkXgjBIfxvBLrAlJX2ztuz2hxc3pxSAaRZrSY2b8OYs2H+8jNyF2uMGw4VoTj9ODRFO4xtq6Frm6xixwWPj/BL0ScNacLl54cZpnhmbMXrJrZmgt2PqR9LI9LpPsCjYWiATJP5APEwvR0nfmC6LKCpu7LCtE= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1709027768; c=relaxed/simple; bh=DsTqHA1gngXvsgLv00b6H3ADXeO6AsxHbAjlH1/+H/k=; h=DKIM-Signature:Date:From:To:Subject:Message-ID:MIME-Version; b=KASmiaTkcioCUxDuuYv6l+h2cbPGbeByjrLcboVTU1Q6O0CDPXHYvi0XFDlkxYkoSb5fz28kAfn71bAk8OySaE/PEIMegReq6o/0xz1R32rqpbQgBiiLIBsQLTe0hZdnSuCVyDb4Y3/KDRW7izsizuhUAwv+9lFJ2EG4cmE878k= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1709027766; h=from:from:reply-to:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:mime-version:mime-version: content-type:content-type:in-reply-to:in-reply-to: references:references; bh=IxXHsJPkx0Ht1GpUqNWER8b0ewiu5O1O2tIQXtDokIc=; b=dib/GPZFqMgd95rduq4bLbF9XVzaWyOe2whJlEMpgedlSzdoiZFG9U1bNvaMdMmcMjUiH2 JPcMvXGj9wgxdzYXQ75BfSdJM1CLeY7Cky7yfB33t7m8kx93mTFWQHi6tEaTsmZx8WChpV Yc2H8/LXzBdxeC4BgosmPX2kPqqVRmk= Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-161-RPvxaeEXNsmfxgTi0Rxy0w-1; Tue, 27 Feb 2024 04:56:01 -0500 X-MC-Unique: RPvxaeEXNsmfxgTi0Rxy0w-1 Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.rdu2.redhat.com [10.11.54.5]) (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 F0E0D8A67E6; Tue, 27 Feb 2024 09:56:00 +0000 (UTC) Received: from tucnak.zalov.cz (unknown [10.39.192.25]) by smtp.corp.redhat.com (Postfix) with ESMTPS id B3D4E39CAC; Tue, 27 Feb 2024 09:56:00 +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 41R9twRJ061206 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Tue, 27 Feb 2024 10:55:58 +0100 Received: (from jakub@localhost) by tucnak.zalov.cz (8.17.1/8.17.1/Submit) id 41R9tvDT061205; Tue, 27 Feb 2024 10:55:57 +0100 Date: Tue, 27 Feb 2024 10:55:57 +0100 From: Jakub Jelinek To: Richard Biener , Uros Bizjak , hjl.tools@gmail.com, gcc-patches@gcc.gnu.org Subject: Re: [PATCH] i386: For noreturn functions save at least the bp register if it is used [PR114116] 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.5 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.5 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,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: On Tue, Feb 27, 2024 at 10:13:14AM +0100, Jakub Jelinek wrote: > On Tue, Feb 27, 2024 at 10:04:06AM +0100, Jakub Jelinek wrote: > > > I hope we at least avoid that at -O0, possibly also with -Og? > > > > r14-8495 fixed at least that. > > > > Of course, it can break debugging experience even when the noreturn function > > is compiled with -O2 but some or all callers of that are -O0 or -Og. > > So, if unlucky and e.g. abort function in glibc gets the > > no_callee_saved_registers treatment and actually uses some call saved > > registers, backtraces when something aborts will be worse or useless. > > And we don't even have any attribute which would tell gcc not to do that. > > > > So sure, another option is just revert the PR38534 changes. > > For __libc_start_main, glibc surely just could use no_callee_saved_registers > attribute, because that is typically the outermost frame in backtrace, > there is no need to save those there. > And for kernel if it really wants it and nothing will use the backtraces, > perhaps the patch wouldn't need to be reverted completely but just guarded > the implicit no_callee_saved_registers treatment of noreturn > functions on -mcmodel=kernel or -fno-asynchronous-unwind-tables. So, let's look at admittedly artificial testcase which could very well happen in real world code though, just using some meaningful code creating the register preassure instead of it being created artificially, noipa attribute just a replacement for functions in different TUs or too large to be inlinable, and the noreturn function in a different library where everything is built with -O2, not -O0 or -Og for debugging. Note, it doesn't have to be even abort, can be exit too. I've compiled this with -Og -g with gcc 12, trunk and trunk patched with the patch I've posted, in each case I run it under debugger, type run and bt when it aborts. The gcc 12 case is the expected one: #0 0x00007ffff7dbd765 in abort () from /lib64/libc.so.6 #1 0x00000000004011ca in bar () at /tmp/1.c:30 #2 0x00000000004011f1 in baz (a=a@entry=42, b=b@entry=43, c=c@entry=44, d=d@entry=45, e=e@entry=46, f=f@entry=47, g=48, h=49) at /tmp/1.c:38 #3 0x00000000004012d8 in qux () at /tmp/1.c:55 #4 0x0000000000401319 in main () at /tmp/1.c:62 The gcc trunk hits the backtrace not possible problem because rbp is clobbered and needed in upper frame CFA computation: #0 0x00007ffff7dbd765 in abort () from /lib64/libc.so.6 #1 0x00000000004011b0 in bar () at /tmp/1.c:30 #2 0x00000000004011d1 in baz (a=, b=, c=, d=d@entry=-559038737, e=e@entry=-559038737, f=f@entry=-559038737, g=48, h=49) at /tmp/1.c:38 #3 0x00000000004012a9 in qux () at /tmp/1.c:55 Backtrace stopped: previous frame inner to this frame (corrupt stack?) And in the patched gcc backtrace works but many of the values are bogus: #0 0x00007ffff7dbd765 in abort () from /lib64/libc.so.6 #1 0x00000000004011b1 in bar () at /tmp/1.c:30 #2 0x00000000004011d2 in baz (a=a@entry=42, b=b@entry=43, c=c@entry=44, d=d@entry=-559038737, e=e@entry=-559038737, f=f@entry=-559038737, g=48, h=49) at /tmp/1.c:38 #3 0x00000000004012aa in qux () at /tmp/1.c:55 #4 0x00000000004012e4 in main () at /tmp/1.c:62 extern void abort (void); volatile unsigned v = 0xdeadbeefU; int w; __attribute__((noipa)) void corge (char *p) { (void) p; } __attribute__((noipa)) int foo (int x) { return x; } __attribute__((noipa, noreturn, optimize (2))) void bar (void) { unsigned a = v; unsigned b = v; unsigned c = v; unsigned d = v; unsigned e = v; unsigned f = v; unsigned g = v; unsigned h = v; int i = foo (50); v = a + b + c + d + e + f + g + h; abort (); } __attribute__((noipa)) void baz (int a, int b, int c, int d, int e, int f, int g, int h) { int i = foo (51); if (w) bar (); } __attribute__((noipa)) void qux (void) { int a = foo (42); int b = foo (43); int c = foo (44); int d = foo (45); int e = foo (46); int f = foo (47); int g = foo (48); int h = foo (49); corge (__builtin_alloca (foo (52))); baz (a, b, c, d, e, f, g, h); w++; baz (a, b, c, d, e, f, g, h); baz (a, b, c, d, e, f, g, h); } int main () { qux (); } Jakub