From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14375 invoked by alias); 7 Nov 2005 05:01:47 -0000 Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org Received: (qmail 14362 invoked by uid 22791); 7 Nov 2005 05:01:45 -0000 Received: from nevyn.them.org (HELO nevyn.them.org) (66.93.172.17) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Mon, 07 Nov 2005 05:01:45 +0000 Received: from drow by nevyn.them.org with local (Exim 4.54) id 1EYz8U-0006ou-88; Mon, 07 Nov 2005 00:01:38 -0500 Date: Mon, 07 Nov 2005 05:01:00 -0000 From: Daniel Jacobowitz To: Wu Zhou Cc: Mark Kettenis , gdb@sources.redhat.com Subject: Re: The root cause for SEGV in evaluating fortran function call, any solution or suggestion? Message-ID: <20051107050138.GA26181@nevyn.them.org> Mail-Followup-To: Wu Zhou , Mark Kettenis , gdb@sources.redhat.com References: <20051102145258.GA28372@nevyn.them.org> <200511032134.jA3LYDsT017248@elgar.sibelius.xs4all.nl> <20051107000949.GD19200@nevyn.them.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.8i X-SW-Source: 2005-11/txt/msg00136.txt.bz2 On Mon, Nov 07, 2005 at 12:51:59PM +0800, Wu Zhou wrote: > You are quite right. Following your pointer, I made another patch and it > now passed with both g77 (3.4.4) and gfortran (4.0.1) on a x86 box. I > didn't consider the red zone in AMD64 architecture, so maybe it won't work > on it. I will try to find a chance to test it on other platform, such as > ppc64 or any other platform I can get access to. > > Appended is the patch. Any comments and suggestion are highly > appreciated! Just to be clear: the patch is _not_ acceptable as is. We need to decide what gfortran's debugging information should look like, and how the transformation should be controlled by language. Casting an integer to a pointer by pushing it to the stack this way is not the correct behavior for any other language. But thanks for testing my suggestion; the general approach looks sound, once we figure out how to integrate it. -- Daniel Jacobowitz CodeSourcery, LLC