From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16464 invoked by alias); 11 Jul 2006 21:34:47 -0000 Received: (qmail 16452 invoked by uid 22791); 11 Jul 2006 21:34:44 -0000 X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 11 Jul 2006 21:34:39 +0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k6BLYbXR024883; Tue, 11 Jul 2006 17:34:37 -0400 Received: from pobox.toronto.redhat.com (pobox.toronto.redhat.com [172.16.14.4]) by int-mx1.corp.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k6BLYbfb021974; Tue, 11 Jul 2006 17:34:37 -0400 Received: from [172.16.14.67] (towel.toronto.redhat.com [172.16.14.67]) by pobox.toronto.redhat.com (8.12.8/8.12.8) with ESMTP id k6BLYbve018707; Tue, 11 Jul 2006 17:34:37 -0400 Message-ID: <44B4196D.8070808@redhat.com> Date: Tue, 11 Jul 2006 21:34:00 -0000 From: Bryce McKinlay User-Agent: Thunderbird 1.5 (X11/20051025) MIME-Version: 1.0 To: Ranjit Mathew CC: java-patches@gcc.gnu.org Subject: Re: [MinGW] RFA: Make Stack Traces Work for Interpreted Code on Windows References: <44B3E70F.4070009@redhat.com> <39399b9d0607111134yb7d0314i1e68fa4ef6773b03@mail.gmail.com> In-Reply-To: <39399b9d0607111134yb7d0314i1e68fa4ef6773b03@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact java-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: java-patches-owner@gcc.gnu.org X-SW-Source: 2006-q3/txt/msg00105.txt.bz2 Ranjit Mathew wrote: >> Note that even then there are some situations (invocation API) where >> neither _Jv_RunMain or _Jv_ThreadStart will be on the stack. > > ...would you happen to know what *will* be there on the call stack > in this case? I don't think there is anything guaranteed in the invocation API case. For JNI you could look for the various JNI Call* functions, but even then it is tricky to figure out whether the frame you are looking at is the outermost JNI call. >> This part of the patch is a bit awkward - duplicating the >> interpreter-specific code is fragile and will make maintenance more >> difficult. Couldn't we instead have fallback_backtrace call the real >> UnwindTraceFn? I believe _Unwind_context is an opaque type, so it should >> be possible to have fallback_backtrace pass its own data there. > > I sort of agree. However, if you look at the code there, it > calls _Unwind_GetRegionStart() and _Unwind_GetIPInfo() - I'll > have to #ifdef these out and somehow shoehorn the SJLJ EH > equivalents in there since the default implementations of > these functions provided by GCC for SJLJ EH are of no use to > us. I think you could just overload them with #defines in backtrace.h? Failing that, I think that adding a couple of #ifdef's in UnwindTraceFn is not as bad as the code duplication. >> Hmm. There shouldn't be any problems here (on Linux) - do you have a >> test case? > > Yes. See: > - ---------------------------- 8< ---------------------------- > 1 public class Ex { > 2 void snafu( ) throws Exception { > 3 throw new Exception( "I do not like you!"); > 4 } > 5 void bar( ) throws Exception { > 6 snafu( ); > 7 } > 8 void foo( ) throws Exception { > 9 bar( ); > 10 } > 11 public static void main( String[] args) throws Exception { > 12 new Ex( ).foo( ); > 13 } > 14 } > - ---------------------------- 8< ---------------------------- Hmm, ok, I see this too. I've filed a bug: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28352 Bryce