From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11577 invoked by alias); 19 Oct 2005 16:14:53 -0000 Mailing-List: contact java-prs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: java-prs-owner@gcc.gnu.org Received: (qmail 11562 invoked by uid 48); 19 Oct 2005 16:14:52 -0000 Date: Wed, 19 Oct 2005 16:14:00 -0000 Message-ID: <20051019161452.11561.qmail@sourceware.org> X-Bugzilla-Reason: CC References: Subject: [Bug libgcj/17021] libgcj verifier resolves classes too eagerly In-Reply-To: Reply-To: gcc-bugzilla@gcc.gnu.org To: java-prs@gcc.gnu.org From: "thebohemian at gmx dot net" X-SW-Source: 2005-q4/txt/msg00167.txt.bz2 List-Id: ------- Comment #11 from thebohemian at gmx dot net 2005-10-19 16:14 ------- In the JavaUtils class of axis 1.2 RC2 contains the following instruction: 639: invokevirtual With a missing DataHandler class file this JavaUtils class can be verified successfully on sun' s jvm but fails at this instruction on gij. I traced the problem back to a call to in _Jv_BytecodeVerifier::ref_intersection::compatible(_Jv_BytecodeVerifier::ref_intersection*, _Jv_BytecodeVerifier*) In that method the names of the two classes (which are not resolved) are the following: (gdb) putf self->data.name $152 = 0x121054 "javax.activation.DataHandler" (gdb) putf other_iter->data.name $153 = 0x80736ac "Ljavax.activation.DataHandler;" Obviously this denotes the same classnames but for Jv_equalUtf8Consts which is called in _Jv_BytecodeVerifier::ref_intersection::compatible() the strings are different. I propose to fix the problem in the following way: Instead of if (! self->is_resolved && ! other_iter->is_resolved && _Jv_equalUtf8Consts (self->data.name, other_iter->data.name)) do if (! self->is_resolved && ! other_iter->is_resolved && ( _Jv_equalUtf8Consts (self->data.name, other_iter->data.name) || match_classname(self->data.name, other_iter->data.name ) ) match_classname is then implemented in a way that it would accept all these names as equal: java/lang/Class Ljava/lang/Class; java.lang.Class Ljava.lang.Class; However there might be another approach to the problem: One could make sure that class names in _Jv_UTF8_Const objects are always in the Lp1/p2/p3/classname; form. Please comment. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17021