From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16880 invoked by alias); 27 Jun 2006 19:57:32 -0000 Received: (qmail 16871 invoked by uid 22791); 27 Jun 2006 19:57:31 -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, 27 Jun 2006 19:57:30 +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 k5RJvSVY007048; Tue, 27 Jun 2006 15:57:28 -0400 Received: from opsy.redhat.com (vpn50-134.rdu.redhat.com [172.16.50.134]) by int-mx1.corp.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k5RJvRCo016651; Tue, 27 Jun 2006 15:57:28 -0400 Received: by opsy.redhat.com (Postfix, from userid 500) id 069AA2DC24F; Tue, 27 Jun 2006 13:53:51 -0600 (MDT) To: Ranjit Mathew Cc: java-patches@gcc.gnu.org Subject: Re: [MinGW] RFC/RFA: Get Partial Stack Traces on Windows References: <44A02481.207@gmail.com> From: Tom Tromey Reply-To: tromey@redhat.com X-Attribution: Tom Date: Tue, 27 Jun 2006 19:57:00 -0000 In-Reply-To: Message-ID: User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3.50 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii 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-q2/txt/msg00506.txt.bz2 >>>>> "Ranjit" == Ranjit Mathew writes: Ranjit> Here's the third revision of this patch that implements Andrew's Ranjit> suggestion. Since the other typedefs in javaprims.h seem to Ranjit> omit the "_t" suffix, I've omitted it here as well. Either is fine by me. The comment helps, thanks. Ranjit> By the way, the reason main() does not appear in the stack trace Ranjit> is because it is called indirectly by call_main() in Ranjit> "gnu/java/lang/natMainThread.cc". The generated code is something Ranjit> like "CALL %8(%EBX)" instead of the normal "CALL xyz". Weird. We do this in at least one other place as well -- Class.newInstance. Ranjit> +// Types to use when treating a pointer as an integer. Similar to Ranjit> +// intptr_t and uintptr_t in C99. Ranjit> +typedef int _Jv_intptr __attribute__((__mode__(__pointer__))); Ranjit> +typedef unsigned int _Jv_uintptr __attribute__((__mode__(__pointer__))); I tend to think we just want one of these. I couldn't think of a situation where I'd need both. Ranjit> OK to apply? I'm going to defer to Bryce and/or Andrew on this one. Tom