From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24815 invoked by alias); 16 Dec 2013 16:19:10 -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 24806 invoked by uid 89); 16 Dec 2013 16:19:10 -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:19:09 +0000 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id rBGGJ6N1010938 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 16 Dec 2013 11:19:06 -0500 Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.ams2.redhat.com [10.39.146.11]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id rBGGJ370006927; Mon, 16 Dec 2013 11:19:05 -0500 Message-ID: <52AF27F7.2060500@redhat.com> Date: Mon, 16 Dec 2013 16:19: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: Yao Qi 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> <52ABF8D7.1050805@codesourcery.com> In-Reply-To: <52ABF8D7.1050805@codesourcery.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-SW-Source: 2013-12/txt/msg00577.txt.bz2 On 12/14/2013 06:21 AM, Yao Qi wrote: > On 12/14/2013 01:49 AM, Pedro Alves wrote: >> gdb/ >> 2013-12-13 Pedro Alves >> >> * frame.h (enum frame_id_stack_status): New enum. >> (struct frame_id) : Adjust comment. >> : Delete field, replaced with ... >> : ... this new field. >> (frame_id_build_unavailable_stack): Declare. >> * frame.c (frame_addr_hash, fprint_field, outer_frame_id) >> (frame_id_build_special): Adjust. >> (frame_id_build_unavailable_stack): New function. >> (frame_id_build, frame_id_build_wild): Adjust. >> (frame_id_p, frame_id_eq, frame_id_inner): Adjust to take into >> account frames with unavailable stack. >> >> * amd64-tdep.c (amd64_frame_this_id) >> (amd64_sigtramp_frame_this_id, amd64_epilogue_frame_this_id): Use >> frame_id_build_unavailable_stack. >> * dwarf2-frame.c (dwarf2_frame_this_id): Likewise. > > Do we need to update tailcall_frame_this_id as well? In case of trace frame debugging, I don't think you can ever have a tailcall frame on top of a frame with unavailable stack, because dwarf2_tailcall_sniffer_first will throw an error computing prev_sp. But even if that would work somehow: static void tailcall_frame_this_id (struct frame_info *this_frame, void **this_cache, struct frame_id *this_id) { struct tailcall_cache *cache = *this_cache; struct frame_info *next_frame; /* Tail call does not make sense for a sentinel frame. */ next_frame = get_next_frame (this_frame); gdb_assert (next_frame != NULL); *this_id = get_frame_id (next_frame); ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ (*this_id).code_addr = get_frame_pc (this_frame); (*this_id).code_addr_p = 1; (*this_id).artificial_depth = (cache->chain_levels - existing_next_levels (this_frame, cache)); gdb_assert ((*this_id).artificial_depth > 0); } ... the tailcall frame's ID's stack components (address and status) are copied from the next frame's stack components. Seems right to me. >> @@ -169,6 +187,12 @@ extern struct frame_id frame_id_build_special (CORE_ADDR stack_addr, >> CORE_ADDR code_addr, >> CORE_ADDR special_addr); >> >> +/* Construct a frame ID representing a frame where the stack address >> + exists, but is unavailable. The first parameter is the frame's > > Remove "first"? since we only have one parameter here. Indeed. Fixed locally. > >> + constant code address (typically the entry point). The special >> + identifier address is set to indicate a wild card. */ >> +extern struct frame_id frame_id_build_unavailable_stack (CORE_ADDR code_addr); >> + > > What does the last sentence mean in the comments? > The same comment is in frame_id_build. Re. what is means, see struct frame_id: /* The frame's special address. This shall be constant through out the lifetime of the frame. This is used for architectures that may have frames that do not change the stack but are still distinct and have some form of distinct identifier (e.g. the ia64 which uses a 2nd stack for registers). This field is treated as unordered - i.e. will not be used in frame ordering comparisons. This field is valid only if special_addr_p is true. Otherwise, this frame is considered to have a wildcard special address, i.e. one that ^^^^^^^^^^^^^ matches every address value in frame comparisons. */ ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ CORE_ADDR special_addr; -- Pedro Alves