From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 127833 invoked by alias); 15 Feb 2016 09:51:17 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 127811 invoked by uid 89); 15 Feb 2016 09:51:16 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD,SPF_PASS autolearn=ham version=3.3.2 spammy=commercial, Tel, office, tel X-HELO: mga01.intel.com Received: from mga01.intel.com (HELO mga01.intel.com) (192.55.52.88) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 15 Feb 2016 09:51:15 +0000 Received: from orsmga001.jf.intel.com ([10.7.209.18]) by fmsmga101.fm.intel.com with ESMTP; 15 Feb 2016 01:51:00 -0800 X-ExtLoop1: 1 Received: from irsmsx151.ger.corp.intel.com ([163.33.192.59]) by orsmga001.jf.intel.com with ESMTP; 15 Feb 2016 01:50:59 -0800 Received: from irsmsx104.ger.corp.intel.com ([169.254.5.210]) by IRSMSX151.ger.corp.intel.com ([169.254.4.108]) with mapi id 14.03.0248.002; Mon, 15 Feb 2016 09:50:58 +0000 From: "Metzger, Markus T" To: Pedro Alves , Joel Brobecker CC: "gdb-patches@sourceware.org" Subject: RE: [PATCH v2 2/3] frame: use get_prev_frame_always in skip_tailcall_frames Date: Mon, 15 Feb 2016 09:51:00 -0000 Message-ID: References: <1454681922-2228-1-git-send-email-markus.t.metzger@intel.com> <1454681922-2228-2-git-send-email-markus.t.metzger@intel.com> <20160207130057.GE20874@adacore.com> <56B9D08F.6060507@redhat.com> <20160209115819.GH15342@adacore.com> <56B9FA90.5030602@redhat.com> In-Reply-To: Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes X-SW-Source: 2016-02/txt/msg00455.txt.bz2 > -----Original Message----- > From: Metzger, Markus T > Sent: Tuesday, February 9, 2016 4:20 PM > To: Pedro Alves ; Joel Brobecker > > Cc: gdb-patches@sourceware.org > Subject: RE: [PATCH v2 2/3] frame: use get_prev_frame_always in > skip_tailcall_frames > > > I'm beginning to wonder if not all-but-the-backtrace-command-related > > > get_prev_frame calls should really be calling get_prev_frame_always. > > > > > > The _always extension isn't very intuitive, though, given that this > > > should be the standard function to use. Should get_prev_frame maybe > > > be renamed to something like get_prev_frame_within_limit and > > > get_prev_frame_always to get_prev_frame? > > > > Maybe a good idea. See also: > > > > https://sourceware.org/bugzilla/show_bug.cgi?id=3D15558 > > > > I just noticed/remembered something -- the check for backtracing past > > main and the entry point is in get_prev_frame, get_prev_frame_always > > bypasses it. > > > > This means that with your change, I think gdb now allows "finish" in > > "main" or in "_start". > > > > Maybe not a bad change, but I though it'd call it out explicitly. >=20 > There are 46 calls to get_prev_frame ignoring this patch. Each of them > should maybe be modified to call get_prev_frame_always, instead. And > none of this is currently covered by the test suite. I'm wondering in which cases GDB should ignore the user-defined backtrace limit. And if GDB should ignore it at all. If the limit is set, some aspects of GDB may not function any longer. But = that's to be expected, isn't it? GDB shouldn't crash, of course. But I'm not sure if it should ignore user = settings in too many cases. Maybe we should even switch back to get_prev_frame in skip_artificial_frames and rely on handling the NULL return if we exceed the backtrace limit? Regards, Markus. Intel Deutschland GmbH Registered Address: Am Campeon 10-12, 85579 Neubiberg, Germany Tel: +49 89 99 8853-0, www.intel.de Managing Directors: Christin Eisenschmid, Christian Lamprechter Chairperson of the Supervisory Board: Nicole Lau Registered Office: Munich Commercial Register: Amtsgericht Muenchen HRB 186928