From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gdb-patches-return-31259-listarch-gdb-patches=sources.redhat.com@sources.redhat.com>
Received: (qmail 13396 invoked by alias); 3 Mar 2004 18:34:28 -0000
Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm
Precedence: bulk
List-Subscribe: <mailto:gdb-patches-subscribe@sources.redhat.com>
List-Archive: <http://sources.redhat.com/ml/gdb-patches/>
List-Post: <mailto:gdb-patches@sources.redhat.com>
List-Help: <mailto:gdb-patches-help@sources.redhat.com>, <http://sources.redhat.com/ml/#faqs>
Sender: gdb-patches-owner@sources.redhat.com
Received: (qmail 13367 invoked from network); 3 Mar 2004 18:34:27 -0000
Received: from unknown (HELO localhost.redhat.com) (216.129.200.20)
  by sources.redhat.com with SMTP; 3 Mar 2004 18:34:27 -0000
Received: from gnu.org (localhost [127.0.0.1])
	by localhost.redhat.com (Postfix) with ESMTP
	id 5CBCF2B92; Wed,  3 Mar 2004 13:34:23 -0500 (EST)
Message-ID: <4046252F.7020504@gnu.org>
Date: Wed, 03 Mar 2004 18:34:00 -0000
From: Andrew Cagney <cagney@gnu.org>
User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-US; rv:1.4.1) Gecko/20040217
MIME-Version: 1.0
To: Daniel Jacobowitz <drow@false.org>
Cc: gdb-patches@sources.redhat.com
Subject: Re: [rfc] trad-frame change
References: <40460B28.3000504@gnu.org> <20040303164933.GB18032@nevyn.them.org>
In-Reply-To: <20040303164933.GB18032@nevyn.them.org>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-SW-Source: 2004-03.o/txt/msg00050.txt
Message-ID: <20040303183400.IbrsIn2DnwDMSc8LcK6snjZ-rUbiftvystwDuCZISEs@z>

> Sounds pretty nice to me.  For what it's worth, I'm testing a sigtramp
> unwinder on MIPS/Linux that could almost but not quite use this:
> 
> +struct mips_prologue_cache
> +{
> +  /* The stack pointer at the time this frame was created; i.e. the
> +     caller's stack pointer when this function was called.  It is used
> +     to identify this frame.  */
> +  CORE_ADDR prev_sp;
> +
> +  CORE_ADDR tramp_start;
> +
> +  int kind;
> +
> +  /* Saved register offsets.  */
> +  struct trad_frame_saved_reg *saved_regs;
> +};
> 
> (so that the frame ID is constant for both instructions of the
> trampoline).

.. and frame_id_unwind() looks something like:

	frame_id_build (cache->prev_sp, cache->tramp_start)?

the trad-frame chache instead has the field:

     struct frame_id this_id;

which is equivalent - the ID being constructed up front.

What is "kind"?

Andrew