From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from gateway36.websitewelcome.com (gateway36.websitewelcome.com [192.185.184.18]) by sourceware.org (Postfix) with ESMTPS id 52E22389851B for ; Thu, 18 Jun 2020 21:15:39 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 52E22389851B Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=tromey.com Authentication-Results: sourceware.org; spf=fail smtp.mailfrom=tom@tromey.com Received: from cm10.websitewelcome.com (cm10.websitewelcome.com [100.42.49.4]) by gateway36.websitewelcome.com (Postfix) with ESMTP id EB14942986397 for ; Thu, 18 Jun 2020 15:28:41 -0500 (CDT) Received: from box5379.bluehost.com ([162.241.216.53]) by cmsmtp with SMTP id m1kzjQXhqXGIkm1kzjwu4F; Thu, 18 Jun 2020 16:07:33 -0500 X-Authority-Reason: nr=8 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=tromey.com; s=default; h=Content-Type:MIME-Version:Message-ID:In-Reply-To:Date: References:Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=pgKQSVCG1/c4ivkLr+T1avKwougqtykU8H2HsRi5bVs=; b=DQCedyPQmXKW4HBggFiPB4siGb 78lfqEXW1kdiaZ16V/fLdRUK+U9JlCqCOXuslv5GoVkr5sl1YOQEl/yyXmQ/a3drtaVwCb9izwBMs 5P0Ryu70FuQmsCxvWf0/M5if5; Received: from 174-16-104-48.hlrn.qwest.net ([174.16.104.48]:57540 helo=murgatroyd) by box5379.bluehost.com with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93) (envelope-from ) id 1jm1ky-003xXg-U1; Thu, 18 Jun 2020 15:07:33 -0600 From: Tom Tromey To: Andrew Burgess Cc: Tom Tromey , gdb-patches@sourceware.org Subject: Re: [PATCH] Find tailcall frames before inline frames References: <20200220155820.22809-1-tromey@adacore.com> <20200618182502.GD2737@embecosm.com> X-Attribution: Tom Date: Thu, 18 Jun 2020 15:07:32 -0600 In-Reply-To: <20200618182502.GD2737@embecosm.com> (Andrew Burgess's message of "Thu, 18 Jun 2020 19:25:02 +0100") Message-ID: <87zh90ytez.fsf@tromey.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - box5379.bluehost.com X-AntiAbuse: Original Domain - sourceware.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - tromey.com X-BWhitelist: no X-Source-IP: 174.16.104.48 X-Source-L: No X-Exim-ID: 1jm1ky-003xXg-U1 X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: 174-16-104-48.hlrn.qwest.net (murgatroyd) [174.16.104.48]:57540 X-Source-Auth: tom+tromey.com X-Email-Count: 3 X-Source-Cap: ZWx5bnJvYmk7ZWx5bnJvYmk7Ym94NTM3OS5ibHVlaG9zdC5jb20= X-Local-Domain: yes X-Spam-Status: No, score=-3028.1 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, JMQ_SPF_NEUTRAL, RCVD_IN_ABUSEAT, RCVD_IN_BARRACUDACENTRAL, RCVD_IN_DNSWL_NONE, SPF_HELO_PASS, SPF_NEUTRAL, TXREP autolearn=no autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jun 2020 21:15:40 -0000 >>>>> "Andrew" == Andrew Burgess writes: >> However, in this scenario, what happened is that the DWARF unwinder >> did find tailcall frames -- but then the PC of the first such frame >> was recognized and claimed by the inline frame sniffer. Andrew> I'm trying to understand the setup you have here in the hope I might Andrew> be able to craft a test case for this - given that I'm not convinced Andrew> the new placement of the tail call sniffer is safe. Andrew> Was the setup something like: Andrew> ,-- f3 tail calls to f4. Andrew> | Andrew> | Andrew> f1 --> f2 --> f3 --> f4 --> f5 --> f6 Andrew> |_______________| Andrew> All inlined in f1 Andrew> Was there anything else special about this case? I feel like there Andrew> must have been, but I don't really understand the problem description. Sorry about that. While I do still have the test executable and core file (and so I can easily try any patches), I can't send them out. I'm happy to test patches. I only vaguely remember the details, and I can't really re-debug the problem in the near term (I'm on PTO next week...). However, I do also have some notes, though not exhaustive ones. Looking at the backtrace now, it does seem be like the above. Here's some heavily trimmed down output: (gdb) frame apply 7 info frame [...] Stack level 0, frame at 0x7ffffffb07c0: called by frame at 0x7ffffffb07c0 Stack level 1, frame at 0x7ffffffb07c0: tail call frame, caller of frame at 0x7ffffffb07c0 Stack level 2, frame at 0x7ffffffb07c0: tail call frame, caller of frame at 0x7ffffffb07c0 Stack level 3, frame at 0x7ffffffb0ab0: called by frame at 0x7ffffffb8c80, caller of frame at 0x7ffffffb07c0 Stack level 4, frame at 0x7ffffffb8c80: inlined into frame 5, caller of frame at 0x7ffffffb0ab0 Stack level 5, frame at 0x7ffffffb8c80: called by frame at 0x7ffffffb8cc0, caller of frame at 0x7ffffffb8c80 Stack level 6, frame at 0x7ffffffb8cc0: called by frame at 0x7ffffffba490, caller of frame at 0x7ffffffb8c80 All I recall is what I wrote: dwarf2_tailcall_sniffer_first would note that a frame came from tailcalls -- so tailcall_frame_sniffer would be expected to notice this. However, the inline sniffer would grab it first, causing confusion. One thing that would have helped here was the ability to turn off inline and/or tail-call unwinding. Perhaps we should add settings for this. I wonder if I erred in my analysis and there's a combination of tail-call and inlining happening. That certainly seems like a possibility and would explain the confusion ... whereas the "info frame" stuff above seems innocuous to me now. Tom