From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gdb-patches-return-32879-listarch-gdb-patches=sources.redhat.com@sources.redhat.com>
Received: (qmail 18398 invoked by alias); 7 May 2004 01:19:41 -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 18321 invoked from network); 7 May 2004 01:19:39 -0000
Received: from unknown (HELO mx1.redhat.com) (66.187.233.31)
  by sources.redhat.com with SMTP; 7 May 2004 01:19:39 -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 i471Jc0o021414
	for <gdb-patches@sources.redhat.com>; Thu, 6 May 2004 21:19:38 -0400
Received: from localhost.redhat.com (to-dhcp51.toronto.redhat.com [172.16.14.151])
	by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i46JX4v06184;
	Thu, 6 May 2004 15:33:04 -0400
Received: from gnu.org (localhost [127.0.0.1])
	by localhost.redhat.com (Postfix) with ESMTP
	id 1CDF02B9D; Thu,  6 May 2004 15:33:05 -0400 (EDT)
Message-ID: <409A92F0.2050209@gnu.org>
Date: Fri, 07 May 2004 01:19:00 -0000
From: Andrew Cagney <cagney@gnu.org>
User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-GB; rv:1.4.1) Gecko/20040217
MIME-Version: 1.0
To: Randolph Chung <randolph@tausq.org>
Cc: gdb-patches@sources.redhat.com
Subject: Re: [patch] sigaltstack fixes for hppa-linux
References: <20040504150219.GJ3965@tausq.org>
In-Reply-To: <20040504150219.GJ3965@tausq.org>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-SW-Source: 2004-05/txt/msg00166.txt.bz2

> This patch fixes sigaltstack handling on hppa. It requires one arch-indep 
> change in frame.c: on hppa (stack-grows-up), the relationship of the 
> sigaltstack can be that it is not "inner" to the signal frame, if the 
> sigaltstack resides in a caller's stack frame (as is true in gdb's testcase.)

The current code handles the transition:

stk 1: caller (this_frame)
stk 2: trampoline (this_frame->next)
stk 2: handler

are you saying that the transition:

stk 1: caller
stk 1: trampoline (this_frame)
stk 2: handler (this_frame->next)

is also possible?

Perhaphs the test should be just:

    if (this_frame->type == NORMAL_FRAME
        && this_frame->next->type == NORMAL_FRAME
        && frame_id_inner (get_frame_id (this_frame),
  			 get_frame_id (this_frame->next)))

Andrew

> ok to apply?