From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 40912 invoked by alias); 11 Feb 2016 15:58:11 -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 40682 invoked by uid 89); 11 Feb 2016 15:58:11 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.1 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=Hx-languages-length:1357 X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Thu, 11 Feb 2016 15:58:08 +0000 Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) by mx1.redhat.com (Postfix) with ESMTPS id B5CC28F296; Thu, 11 Feb 2016 15:58:06 +0000 (UTC) Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.phx2.redhat.com [10.5.9.1]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u1BFw55L029691; Thu, 11 Feb 2016 10:58:06 -0500 Message-ID: <56BCAF8D.8030303@redhat.com> Date: Thu, 11 Feb 2016 15:58:00 -0000 From: Pedro Alves User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: "Metzger, Markus T" CC: "gdb-patches@sourceware.org" Subject: Re: [PATCH v2 3/3] btrace, frame: fix crash in get_frame_type References: <1454681922-2228-1-git-send-email-markus.t.metzger@intel.com> <1454681922-2228-3-git-send-email-markus.t.metzger@intel.com> <56B9D620.2020104@redhat.com> <56BA61C6.8060807@redhat.com> <56BB0A0D.80502@redhat.com> <56BB5872.2000604@redhat.com> <56BC8EF0.4000202@redhat.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-SW-Source: 2016-02/txt/msg00358.txt.bz2 On 02/11/2016 03:42 PM, Metzger, Markus T wrote: >> If we don't know where the caller is, we can't skip the resolver in one go, so >> best to do is probably to return 0, and let infrun's stepping logic continue >> single-stepping. > > You think we should add the check nevertheless in gdb/glibc-tdep.c? Let's leave it be. If may be that the use case that trips on it would be best fixed differently. > > The others I won't be able to test. I could do the changes and rely on buildbot > to flag issues. If we really want to change them. I don't think we should change the others without evidence that they'd need it. If we do trip on problems on those, I think the fix should be elsewhere. I'd still early in the release cycle, let's wait and see. > > commit 0dc54d83f375e8901061244807e078f281fca070 > Author: Markus Metzger > Date: Thu Feb 11 11:07:09 2016 +0100 > > stack: check frame_unwind_caller_id > > Callers of frame_unwind_caller_* functions are supposed to check > frame_unwind_caller_id. > > Add such a check to frame_info and treat an invalid caller ID as if the caller > PC were not available. > > 2016-02-11 Markus Metzger > > gdb/ > * stack.c (frame_info): Check frame_unwind_caller_id. > OK. Thanks, Pedro Alves