From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20655 invoked by alias); 12 Dec 2013 19:55:40 -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 20643 invoked by uid 89); 12 Dec 2013 19:55:40 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-4.1 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; Thu, 12 Dec 2013 19:55:39 +0000 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id rBCJtasu001635 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 12 Dec 2013 14:55:37 -0500 Received: from host2.jankratochvil.net (ovpn-116-40.ams2.redhat.com [10.36.116.40]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id rBCJtVRW003024 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 12 Dec 2013 14:55:34 -0500 Date: Thu, 12 Dec 2013 19:55:00 -0000 From: Jan Kratochvil To: Pedro Alves Cc: Markus Metzger , gdb-patches@sourceware.org Subject: Re: [patch v8 05/24] frame: artificial frame id's Message-ID: <20131212195531.GA6092@host2.jankratochvil.net> References: <1386839747-8860-1-git-send-email-markus.t.metzger@intel.com> <1386839747-8860-6-git-send-email-markus.t.metzger@intel.com> <52AA10DD.2020506@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <52AA10DD.2020506@redhat.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-IsSubscribed: yes X-SW-Source: 2013-12/txt/msg00513.txt.bz2 On Thu, 12 Dec 2013 20:39:09 +0100, Pedro Alves wrote: > To be more precise, the frames do have a stack, but it's . > I.e., it existed, but we didn't capture it, so we can't retrieve it. > I presume "p $sp" etc. will show , right? Right. > > To prepare for this, support frame_id's without a stack component. > > So special_addr will be a made up number, right? Will each such > frame have its own special_addr ? Yes. > Looks like frame_ id_eq (null_frame_id, null_frame_id) now > returns true, while it returns false before. If you discussed > all this and came to the conclusion it's OK, please document > it in the commit log. In any case (I'm not sure offhand if > that's OK), the NaN comment above is no longer correct, > and neither is this one: That was not needed / intentional so it would be better to keep the original behavior. Thanks, Jan