From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29474 invoked by alias); 16 Dec 2013 16:25:18 -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 29463 invoked by uid 89); 16 Dec 2013 16:25:18 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.2 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 ESMTP; Mon, 16 Dec 2013 16:25:17 +0000 Received: from int-mx02.intmail.prod.int.phx2.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id rBGGPFDU014566 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 16 Dec 2013 11:25:15 -0500 Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.ams2.redhat.com [10.39.146.11]) by int-mx02.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id rBGGPDl6028879; Mon, 16 Dec 2013 11:25:14 -0500 Message-ID: <52AF2965.8070902@redhat.com> Date: Mon, 16 Dec 2013 16:25:00 -0000 From: Pedro Alves User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130625 Thunderbird/17.0.7 MIME-Version: 1.0 To: "Metzger, Markus T" CC: "gdb-patches@sourceware.org" Subject: Re: [PATCH] "tfind" across unavailable-stack frames. References: <1366214779.30939.1@abidh-ubunto1104> <516F11B9.8030202@redhat.com> <52AB48B6.6040206@redhat.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-SW-Source: 2013-12/txt/msg00578.txt.bz2 On 12/16/2013 08:39 AM, Metzger, Markus T wrote: >> -----Original Message----- >> From: gdb-patches-owner@sourceware.org [mailto:gdb-patches- >> owner@sourceware.org] On Behalf Of Pedro Alves >> Sent: Friday, December 13, 2013 6:50 PM > > >> +/* See frame.h. */ >> + >> +struct frame_id >> +frame_id_build_unavailable_stack (CORE_ADDR code_addr) >> +{ >> + struct frame_id id = null_frame_id; >> + >> + id.stack_status = FID_STACK_UNAVAILABLE; >> + id.code_addr = code_addr; >> + id.code_addr_p = 1; >> + return id; >> +} > > For record-btrace, we would also need to allow special_addr. > I can also add another build function for this case. Yes, quite similar to the one you were adding. >> struct frame_info; >> @@ -97,8 +115,8 @@ struct frame_id >> function pointer register or stack pointer register. They are >> wrong. >> >> - This field is valid only if stack_addr_p is true. Otherwise, this >> - frame represents the null frame. */ >> + This field is valid only if frame_id.stack_status is >> + FID_STACK_VALID. */ >> CORE_ADDR stack_addr; > > Maybe the comment should say that this field must be zero unless > stack_status == FID_STACK_VALID. > > Frame_id_eq would compare stack_addr if stack_status compares > equal. Indeed. I'll do that. I had considered changing frame_id_eq to only compare stack_addr if stack_status == FID_STACK_VALID, but then since in practice we always centrally control what we put in stack_addr, and put 0 zero anyway, might as well just document that, and avoid ever seeing confusing garbage there. Thanks, -- Pedro Alves