From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <frysk-return-2719-listarch-frysk=sources.redhat.com@sourceware.org>
Received: (qmail 12869 invoked by alias); 2 Mar 2008 12:34:34 -0000
Received: (qmail 12862 invoked by uid 22791); 2 Mar 2008 12:34:33 -0000
X-Spam-Status: No, hits=-2.1 required=5.0 	tests=AWL,BAYES_00
X-Spam-Check-By: sourceware.org
Received: from wildebeest.demon.nl (HELO gnu.wildebeest.org) (83.160.170.119)     by sourceware.org (qpsmtpd/0.31) with ESMTP; Sun, 02 Mar 2008 12:34:16 +0000
Received: from wildebeest.demon.nl ([83.160.170.119] helo=[127.0.0.1]) 	by gnu.wildebeest.org with esmtp (Exim 4.63) 	(envelope-from <mark@klomp.org>) 	id 1JVnOO-0005b5-Ae; Sun, 02 Mar 2008 13:34:12 +0100
Subject: Re: [patch] Don't crash on stepping "bad frame"
From: Mark Wielaard <mark@klomp.org>
To: Andrew Cagney <cagney@redhat.com>
Cc: frysk@sourceware.org
In-Reply-To: <47C82C87.4090600@redhat.com>
References: <1204298035.7826.37.camel@dijkstra.wildebeest.org> 	 <47C82C87.4090600@redhat.com>
Content-Type: text/plain
Date: Sun, 02 Mar 2008 12:34:00 -0000
Message-Id: <1204460137.8622.4.camel@localhost.localdomain>
Mime-Version: 1.0
X-Mailer: Evolution 2.12.3 (2.12.3-1.fc8)
Content-Transfer-Encoding: 7bit
X-Spam-Score: -4.0 (----)
X-IsSubscribed: yes
Mailing-List: contact frysk-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Id: <frysk.sourceware.org>
List-Subscribe: <mailto:frysk-subscribe@sourceware.org>
List-Post: <mailto:frysk@sourceware.org>
List-Help: <mailto:frysk-help@sourceware.org>, <http://sourceware.org/lists.html#faqs>
Sender: frysk-owner@sourceware.org
X-SW-Source: 2008-q1/txt/msg00103.txt.bz2

Hi Andrew,

On Fri, 2008-02-29 at 11:02 -0500, Andrew Cagney wrote:
> Interesting work-around; I'll add some comments to explain exactly 
> where/when this senario occures.  And where/when it doesn't.  For 
> instance a step-out through a sigalt stack, whith a bad unwind, will 
> make the wrong decision.

Yes, please do add such documentation if you can. That would be very
valuable.

Note that there isn't any "good" decision really in the case of bad
unwind info where getOuterFrame() has to return null. Currently we try
to get the user back to "known territory", but we could also just drop
the user at the "bad address" and let them sort it out themselves.
Neither is really attractive of course.

Cheers,

Mark