From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28579 invoked by alias); 17 Oct 2003 18:11:26 -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 28564 invoked from network); 17 Oct 2003 18:11:25 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sources.redhat.com with SMTP; 17 Oct 2003 18:11:25 -0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.11.6/8.11.6) with ESMTP id h9HIBPM17308 for ; Fri, 17 Oct 2003 14:11:25 -0400 Received: from pobox.corp.redhat.com (pobox.corp.redhat.com [172.16.52.156]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id h9HIBNr09526; Fri, 17 Oct 2003 14:11:23 -0400 Received: from localhost.localdomain (vpn50-50.rdu.redhat.com [172.16.50.50]) by pobox.corp.redhat.com (8.12.8/8.12.8) with ESMTP id h9HIBMwC026310; Fri, 17 Oct 2003 14:11:23 -0400 Received: (from kev@localhost) by localhost.localdomain (8.11.6/8.11.6) id h9HIBHW32547; Fri, 17 Oct 2003 11:11:17 -0700 Date: Fri, 17 Oct 2003 18:11:00 -0000 From: Kevin Buettner Message-Id: <1031017181116.ZM32546@localhost.localdomain> In-Reply-To: "J. Johnston" "Re: RFA: frame id enhancement" (Oct 16, 5:49pm) References: <3F81DB50.6020202@redhat.com> <3F8DB78A.4090409@redhat.com> <3F8DD464.6050201@redhat.com> <3F8EC2B3.5040100@redhat.com> <3F8EEC26.60101@redhat.com> <3F8F0850.7080104@redhat.com> <3F8F124F.5080509@redhat.com> To: "J. Johnston" , Andrew Cagney Subject: Re: RFA: frame id enhancement Cc: gdb-patches@sources.redhat.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2003-10/txt/msg00591.txt.bz2 On Oct 16, 5:49pm, J. Johnston wrote: > It "is" a register stack on the ia64. Registers r32 - r127 for any frame all > come from this area. It gets bumped up by a special alloc() instruction. I'm > not sure I would call it unordered. It may be better to say that it is treated > as unordered. That would make the comments below much simpler - i.e. the > special_addr field is treated as unordered so it is never used to determine > order when comparing frames. For IA-64, the backing store most certainly is ordered. It is quite possible to have a bunch of consecutive frames which all have the same "sp" value. For these frames, older frames will have smaller bsp values than newer frames. (I.e, the backing store stack grows from lower addresses toward higher addresses.)