From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.220.29]) by sourceware.org (Postfix) with ESMTPS id E230B3858C2C for ; Mon, 13 Feb 2023 14:23:09 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org E230B3858C2C 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 imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by smtp-out2.suse.de (Postfix) with ESMTPS id 287D31F38A; Mon, 13 Feb 2023 14:23:09 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1676298189; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version: content-transfer-encoding:content-transfer-encoding; bh=PaEu3WEOnLW/uPt8ai0jgke/ZgQ/kYUPkH2dgEWNVcg=; b=cZpTswZ/RvcCtVY6yud+HcBv3BaluopFYbrcS+WR/3Vzsnj87oBVw8ecMPbT4smRt8Dh6F 4cxuqEezLflktxzHYsSmPxMkHCv12AMmXv0gExLq4joOW1Do9AqWQVWhmYxxLADK4rGqW3 gSvZ+Cap3sxSvZLx0jy9M6g8HB7BYe8= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1676298189; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version: content-transfer-encoding:content-transfer-encoding; bh=PaEu3WEOnLW/uPt8ai0jgke/ZgQ/kYUPkH2dgEWNVcg=; b=0AXMmS9KzJj2z8ENU2xOA+9/Jtg/T0JrvcLIDr5bGs8He6BdGHVmsAiRnW5MKdMF0xoeAg U+E4JPLWJR8RwlAA== Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by imap2.suse-dmz.suse.de (Postfix) with ESMTPS id 10638138E6; Mon, 13 Feb 2023 14:23:09 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap2.suse-dmz.suse.de with ESMTPSA id Q/3JAs1H6mOwfgAAMHmgww (envelope-from ); Mon, 13 Feb 2023 14:23:09 +0000 From: Tom de Vries To: gdb-patches@sourceware.org Cc: Tom Tromey Subject: [PATCH v2 0/5] [gdb/symtab] Assume epilogue unwind info is valid unless gcc < 4.5.0 Date: Mon, 13 Feb 2023 15:23:04 +0100 Message-Id: <20230213142309.24366-1-tdevries@suse.de> X-Mailer: git-send-email 2.35.3 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-6.3 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,KAM_NUMSUBJECT,KAM_SHORT,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: [ This patch series is a resubmission of this patch ( https://sourceware.org/pipermail/gdb-patches/2023-January/196325.html ). The problem with the earlier version was that I tested it with a broken version of test-case gdb.base/unwind-on-each-insn.exp, something that was fixed by commit d9195131530 ("[gdb/testsuite] Simplify gdb.base/unwind-on-each-insn.exp.tcl"). Retesting with a fixed test-case revealed the need for the patch "[gdb/tdep] Add amd64/i386 epilogue override unwinders". Furthermore, I've added two introductory refactoring patches to make following changes more compact. Now that this turned into a patch series, I've also split off the dwarf2/read.c change into a separate patch. ] The gcc 4.4.x (and earlier) compilers had the problem that the unwind info in the epilogue was inaccurate. In order to work around this in gdb, epilogue unwinders were added with a higher priority than the dwarf unwinders in the amd64 and i386 targets: - amd64_epilogue_frame_unwind, and - i386_epilogue_frame_unwind see: - submission emails: https://sourceware.org/pipermail/gdb-patches/2009-July/066779.html https://sourceware.org/pipermail/gdb-patches/2009-August/067684.html - gdb commits 872761f485e and 06da04c6105 Subsequently, the epilogue unwind info problem got fixed in gcc 4.5.0, see: - submission email https://gcc.gnu.org/pipermail/gcc-patches/2009-May/261377.html - gcc commit cd9c1ca866b - release notes gcc 4.5.0 ( https://gcc.gnu.org/gcc-4.5/changes.html ): GCC now generates unwind info also for epilogues. However, the epilogue unwinders prevented gdb from taking advantage of the fixed epilogue unwind info, so the scope of the epilogue unwinders was limited, bailing out for gcc >= 4.5.0, see: - submisssion email https://sourceware.org/pipermail/gdb-patches/2011-June/083429.html - gdb commit e0d00bc749e "Disable epilogue unwinders on recent GCCs" This scope limitation mechanism works well for gcc -g: the producer is available in the debug info, and we can determine whether we're dealing with reliable epilogue unwind info or not. For gcc -g0 though, epilogue unwind information is available in .eh_frame, but the producer is not availabe to determine whether that information is reliable or not, and consequently the info is ignored: - in the case of using gcc <= 4.4.x, that is the ok decision and we're working around the gcc problem, but - in the case of gcc >= 4.5.0, that means we fail to take advantage of fixed epilogue unwind info. Furthermore, let's review the history of what epilogue unwind information is trusted by gdb: - initial position: trust all information - after the epilogue unwinders were added: trust none - after the scope limitation: only trust gcc >= 4.5.0. So, while we started out with trusting info from all compilers, we end up trusting only gcc >= 4.5.0, which seems a bit of an overreach for a workaround for a problem in the gcc compiler. Fix these two issues by reversing the burden of proof: - currently we assume epilogue unwind info is invalid unless we can proof that gcc >= 4.5.0. - instead, assume epilogue unwind info is valid unless we can proof that gcc < 4.5.0. An added benefit of this is that it makes the amd64 and i386 targets more similar to other targets, which makes comparing behaviour easier. Note that some other targets also have an epilogue unwinder, but none of those have a higher priority than the dwarf unwinders. Tested on x86_64-linux with gcc 7.5.0, with target boards unix/-m64 and unix/-m32. A regression test-case has been added to test the -g0 -fasynchronous-unwind-tables scenario, on amd64 (but not on i386). PR tdep/30028 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30028 --- gdb/amd64-tdep.c | 4 +- gdb/dwarf2/read.c | 12 ++++- gdb/i386-tdep.c | 4 +- .../gdb.base/unwind-on-each-insn-amd64-2.exp | 52 ++++++++++++++++++ .../gdb.base/unwind-on-each-insn-amd64-2.s | 54 +++++++++++++++++++ 5 files changed, 123 insertions(+), 3 deletions(-) create mode 100644 gdb/testsuite/gdb.base/unwind-on-each-insn-amd64-2.exp create mode 100644 gdb/testsuite/gdb.base/unwind-on-each-insn-amd64-2.s Tom de Vries (5): [gdb/symtab] Factor out compunit_epilogue_unwind_valid [gdb/tdep] Fix amd64/i386_stack_frame_destroyed_p [gdb/tdep] Add amd64/i386 epilogue override unwinders [gdb/symtab] Trust epilogue unwind info for unknown producer (-g0 case) [gdb/symtab] Trust epilogue unwind info for unknown or non-gcc producer gdb/amd64-tdep.c | 69 +++++++++++++++--- gdb/dwarf2/read.c | 8 ++- gdb/i386-tdep.c | 71 +++++++++++++++---- gdb/symtab.h | 13 ++++ .../gdb.base/unwind-on-each-insn-amd64-2.exp | 52 ++++++++++++++ .../gdb.base/unwind-on-each-insn-amd64-2.s | 54 ++++++++++++++ 6 files changed, 243 insertions(+), 24 deletions(-) create mode 100644 gdb/testsuite/gdb.base/unwind-on-each-insn-amd64-2.exp create mode 100644 gdb/testsuite/gdb.base/unwind-on-each-insn-amd64-2.s base-commit: 97c195191578e9a68bfbb810eea373f5f3efcb7d -- 2.35.3