From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4628 invoked by alias); 16 Jun 2004 17:33:05 -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 4620 invoked from network); 16 Jun 2004 17:33:04 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org with SMTP; 16 Jun 2004 17:33:04 -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 i5GHX3e3023469 for ; Wed, 16 Jun 2004 13:33:03 -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 i5GHX0005196; Wed, 16 Jun 2004 13:33:00 -0400 Received: from gnu.org (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id 3FC812B9D; Wed, 16 Jun 2004 13:32:41 -0400 (EDT) Message-ID: <40D08438.8090009@gnu.org> Date: Wed, 16 Jun 2004 17:33: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: <200406161348.PAA04636@faui1m.informatik.uni-erlangen.de> In-Reply-To: <200406161348.PAA04636@faui1m.informatik.uni-erlangen.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2004-06/txt/msg00384.txt.bz2 > Andrew Cagney wrote: > > >>> 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. > > > The following patch adds bits to the struct frame_id that explicitly > state whether each of the stack, code, or special addresses is valid. > This removes the need to choose one particular address value to > signify the 'invalid/wildcard/...' state. > > It also adds the frame_id_build_wild function you suggested. > > However, it changes the behaviour in that nobody actually calls _wild > at the moment, since I wasn't sure at what places the code address > actually can be unknown right now. Those places would need to be > adapted later, if required. Right. To find them you'd have to analize all the code paths involving zero values being returned from the symbol table - outch! As found they can be updated (and likely also fix the symtab interface). I should note that I did see such calls in the wild[groan] but only while fixing bugs during a frame conversion. > Tested on s390-ibm-linux and s390x-ibm-linux, fixes the signull > test case failure. Yes with some tweaks: Change s/..._valid/..._p/: It's a consistent, but slightly wierd, naming convention Add some sort of qualifying remark (what, I don't care) to each of the comments: /* The frame's code address. This shall be constant through out the lifetime of the frame. While the PC (a.k.a. resume address) so that its clear that the value is predicated by ..._p. Initialize the id to null vis: struct frame_id id = null_frame_id; id.stack_addr = stack_addr; id.stack_addr_valid = 1; id.code_addr = code_addr; id.code_addr_valid = 1; so that the code is more likely to be future proof. Extend this comment: ! if (!l.stack_addr_valid || !r.stack_addr_valid) /* Like a NaN, if either ID is invalid, the result is false. */ to mention that since a null_frame_id is always invalid it always trips up on that test. with those changes its ok, Thanks! Andrew