From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12945 invoked by alias); 9 Jun 2004 14:55:38 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 12785 invoked from network); 9 Jun 2004 14:55:32 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org with SMTP; 9 Jun 2004 14:55:32 -0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.10/8.12.10) with ESMTP id i59EtWi7001105 for ; Wed, 9 Jun 2004 10:55:32 -0400 Received: from localhost.redhat.com (porkchop.devel.redhat.com [172.16.58.2]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i59EtV000783; Wed, 9 Jun 2004 10:55:31 -0400 Received: from gnu.org (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id 09BC92B9D; Wed, 9 Jun 2004 10:55:25 -0400 (EDT) Message-ID: <40C724DC.1040306@gnu.org> Date: Wed, 09 Jun 2004 14:55:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-GB; rv:1.4.1) Gecko/20040217 MIME-Version: 1.0 To: Ulrich Weigand Cc: Daniel Jacobowitz , gdb-patches@sources.redhat.com Subject: Re: [PATCH] Fix frame ID comparison problem on s390 References: <200406091412.QAA01440@faui1d.informatik.uni-erlangen.de> In-Reply-To: <200406091412.QAA01440@faui1d.informatik.uni-erlangen.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2004-06/txt/msg00175.txt.bz2 > Andrew Cagney wrote: > > >>> Symbol table code often returns 0 to indicate a failed lookup (here a >>> search for the function containing pc). That zero can end up in the >>> frame ID. Look at calls to get_frame_func / frame_func_unwind (which >>> I've proposed eliminating). >>> >>> From memory architectures that do not implement dummy ID unwind also >>> end up with wild-card IDs (fortunatly the dummy-frame code works around >>> this). >>> >>> Broken tramp unwinders often leave the .code address zero (see paragraph >>> #1 for why). > > > So, what would you recommend to solve the problem of 'wildcard zero pc' > being confused with 'NULL pointer call'? Is my original back-end hack > OK with or, or do you have another target-independent suggestion? No. Not really. The wild card mechanism is needed (for when the function entry point address isn't known) but it needs to be made more robust. One step on that path would be to extend the build interface: > /* Construct a frame ID. The first parameter is the frame's constant > stack address (typically the outer-bound), and the second the > frame's constant code address (typically the entry point) (or zero, > to indicate a wild card). The special identifier address is > defaulted to zero. */ > extern struct frame_id frame_id_build (CORE_ADDR stack_addr, > CORE_ADDR code_addr); > > /* Construct a special frame ID. The first parameter is the frame's constant > stack address (typically the outer-bound), the second is the > frame's constant code address (typically the entry point) (or zero, > to indicate a wild card), and the third parameter is the frame's > special identifier address (or zero to indicate a wild card or > unused default). */ > extern struct frame_id frame_id_build_special (CORE_ADDR stack_addr, > CORE_ADDR code_addr, > CORE_ADDR special_addr); with something like: > extern struct frame_id frame_id_build_wild (CORE_ADDR stack_addr); That way clients would explicitly build a wild-card frame ID, and the frame code was free to implement that mechanism anyway it saw fit. Andrew