From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26831 invoked by alias); 19 Jul 2009 13:55:17 -0000 Received: (qmail 26810 invoked by uid 22791); 19 Jul 2009 13:55:15 -0000 X-SWARE-Spam-Status: No, hits=-1.8 required=5.0 tests=AWL,BAYES_00,SARE_MSGID_LONG40,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mail-fx0-f222.google.com (HELO mail-fx0-f222.google.com) (209.85.220.222) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sun, 19 Jul 2009 13:55:08 +0000 Received: by fxm22 with SMTP id 22so1478123fxm.8 for ; Sun, 19 Jul 2009 06:55:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.86.25.19 with SMTP id 19mr2611262fgy.71.1248011704693; Sun, 19 Jul 2009 06:55:04 -0700 (PDT) In-Reply-To: <4A632674.7050501@gmail.com> References: <90baa01f0907180506h1a58152du5d45d66628043ad9@mail.gmail.com> <4A621422.502@gmail.com> <4A621DC3.9080403@redhat.com> <90baa01f0907181222h541dd4ebv1b599c98dc7c1c9c@mail.gmail.com> <90baa01f0907190413j35ab1318qb81d4d3256747d0f@mail.gmail.com> <4A631FB6.1090908@gmail.com> <90baa01f0907190631y182e09aewdccdc711ed39c9b5@mail.gmail.com> <4A632674.7050501@gmail.com> Date: Sun, 19 Jul 2009 13:55:00 -0000 Message-ID: <90baa01f0907190655m14328312g58a6bab47a46a22d@mail.gmail.com> Subject: Re: RFA: libjava seems to miss some files for win32 From: Kai Tietz To: Dave Korn Cc: Andrew Pinski , Andrew Haley , gcc@gcc.gnu.org, java@gcc.gnu.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org X-SW-Source: 2009-07/txt/msg00366.txt.bz2 2009/7/19 Dave Korn : > Kai Tietz wrote: >> 2009/7/19 Dave Korn : >>> Kai Tietz wrote: >>> >>>> There are a lot of issues about casting HANDLE values into jint types, >>>> which is for x86 valid, but for x64 can lead potential to pointer >>>> truncations. Those part need some review by libjava maintainers. My >>>> patch simply casts those kind of pointers via __UINTPTR_TYPE__ into >>>> integer scalar before casting it into jint. I put comments at those >>>> places, where some rework is necessary. >>> =A0Argh. =A0You're replacing a bunch of warnings that draw attention to= a real >>> problem by a bunch of silent fixmes in the code. =A0That's a bit scary = to me. >> >> Right, therefore those comments are for. But otherwise I couldn't get >> it build, as those kind of failures are treated as errors (what is in >> fact a good thing). > > =A0Yes, so since they are a good thing, you should *not* get rid of them.= =A0It > is better for it not to build than for it to silently build bad code. =A0= If you > want it to work, you should make it *actually* work, otherwise just add i= t to > noconfigdirs until such time as you can make it work. =A0There is not onl= y no > point successfully building a broken library, there is _less_ than no poi= nt. > > =A0Whenever adding fixmes, you must plan on there being a very great like= lihood > of them getting forgotten and never fixed. =A0Rule #1 of maintenance-frie= ndly > coding. > >>> =A0Question is, can we change the sizes of the members of class objects= , such >>> as gnu::java::net::PlainSocketImpl::native_fd, or do these objects and = their >>> layout form part of an ABI, and/or do they ever get serialised? =A0The = Java guys >>> will be able to tell us. > >> This was the reason, why I didn't changed api here. The final patch I >> see here done by the java team, as I have no real idea, if those types >> and members are part of abi, here. If it is there are ways to solve >> this (e.g. making abstract handle values for OS handles as example). >> So it is for sure necessary that a java maintainer takes action here. > > =A0I fail to see the value of building a broken libjava for w64. =A0It's = not a > step you need to get past on the roadmap to making a working java for w64. > Just don't build it at all. =A0--disable-libjava or $noconfigdirs. > > =A0Alternatively, wait a few hours until the java guys have a chance to > respond. =A0Maybe we can just change the datatypes, after all. =A0But I r= eally > can't see any use and only harm in adding a silently broken implementatio= n. Well, in standard I agree. But in this special case is the code just broken for apps using more then 32-bit address range for heap (and handles). Btw a run of testsuite works here in pretty much cases. The patch I sent here is more a head-up (and it fixes build for 32-bit windows builds, too). If I keep stuff in my back-chamber, things won't improve and nobody knows that there is an issue present. Cheers, Kai --=20 | (\_/) This is Bunny. Copy and paste | (=3D'.'=3D) Bunny into your signature to help | (")_(") him gain world domination