From owner-freebsd-sparc64@FreeBSD.ORG Sun Feb 22 20:17:03 2004 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5A22A16A4CE for ; Sun, 22 Feb 2004 20:17:03 -0800 (PST) Received: from smtp3.server.rpi.edu (smtp3.server.rpi.edu [128.113.2.3]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1354443D2D for ; Sun, 22 Feb 2004 20:17:03 -0800 (PST) (envelope-from drosih@rpi.edu) Received: from [128.113.24.47] (gilead.netel.rpi.edu [128.113.24.47]) by smtp3.server.rpi.edu (8.12.8/8.12.8) with ESMTP id i1N4H0m1024350; Sun, 22 Feb 2004 23:17:00 -0500 Mime-Version: 1.0 X-Sender: drosih@mail.rpi.edu Message-Id: In-Reply-To: References: <20040215060047.GA62840@dhcp01.pn.xcllnt.net> <20040215165913.M30161@grogged.dyndns.org> Date: Sun, 22 Feb 2004 23:16:58 -0500 To: des@des.no (Dag-Erling =?iso-8859-1?Q?Sm=F8rgrav?= ) From: Garance A Drosihn Content-Type: text/plain; charset="iso-8859-1" ; format="flowed" Content-Transfer-Encoding: quoted-printable X-Scanned-By: CanIt (www . canit . ca) cc: sparc64@freebsd.org Subject: Re: Problem with DHCLIENT vs 64-bit time_t X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2004 04:17:03 -0000 At 11:45 AM +0100 2/22/04, Dag-Erling Sm=F8rgrav wrote: >Garance A Drosihn writes: >> So, there definitely is something wrong with the dhclient from > > the base system But it might be that people having trouble > > with dhcp on 64-bTT sparc systems could use the port, at least > > for the short-term. > >Only takes a few minutes of eyeballing to figure out that the >problem is most likely on line 424 of >src/contrib/isc-dhcp/common/parse.c: > > convert_num (cfile, (unsigned char *)timep, val, 10, 32); > >idiotically, the final argument to convert_num() is supposed to >be the size in bits of the number to store in the location pointed >to by the second argument. The simplest fix is to use a temporary >int32_t and assign it to *timep later, since convert_num() can't >deal with 64-bit quantities. See attached (untested) patch. I added that patch, and it didn't help me. I was also hoping for some quick-fix to jump out at me, so I recompiled dhclient on both i386 and sparc64 with 64-bTT after adding a whole bunch of warning options to CFLAGS. When I did this, I got over a thousand warnings on both platforms... On sparc, I noticed one warning: warning: cast from pointer to integer of different size for #ifdef PTRSIZE_64BIT icmp.icmp_id =3D (((u_int32_t)(u_int64_t)addr) ^ (u_int32_t)(((u_int64_t)addr) >> 32)); #else icmp.icmp_id =3D (u_int32_t)addr; <<<---- this line #endif I defined PTRSIZE_64BIT, and the client worked!!! Well, it only *thought* that it worked, so it went into the background instead of just hanging. But it didn't actually configure the interface, so I reran it and this time it hung the same way it usually does. Damn. I thought I had something there. When comparing the warnings from i386 to those from sparc64, sparc64 sees about 50 extra warnings about: warning: cast increases required alignment of target type Would this be a possible cause of inconsistent (and usually broken) behavior in a program? Do we need to try to fix all of those? The only other "new warning" was: warning: `binding' might be used uninitialized in this function at line 68 in function execute_statements in common/execute.c. However, I couldn't see how that could be uninitialized, and I couldn't see how the logic wrt that variable would *change* based on platform, so I assume that's just a bogus warning. Of course, our problems could easily be due to some of the other 1000 warnings... -- Garance Alistair Drosehn =3D gad@gilead.netel.rpi.edu Senior Systems Programmer or gad@freebsd.org Rensselaer Polytechnic Institute or drosih@rpi.edu