From owner-freebsd-sparc64@FreeBSD.ORG Wed Jun 3 20:05:47 2009 Return-Path: Delivered-To: sparc64@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 597B61065786; Wed, 3 Jun 2009 20:05:47 +0000 (UTC) (envelope-from marius@alchemy.franken.de) Received: from alchemy.franken.de (alchemy.franken.de [194.94.249.214]) by mx1.freebsd.org (Postfix) with ESMTP id C1EB98FC0A; Wed, 3 Jun 2009 20:05:46 +0000 (UTC) (envelope-from marius@alchemy.franken.de) Received: from alchemy.franken.de (localhost [127.0.0.1]) by alchemy.franken.de (8.14.3/8.14.3/ALCHEMY.FRANKEN.DE) with ESMTP id n53JisHU043301; Wed, 3 Jun 2009 21:44:54 +0200 (CEST) (envelope-from marius@alchemy.franken.de) Received: (from marius@localhost) by alchemy.franken.de (8.14.3/8.14.3/Submit) id n53JirEU043300; Wed, 3 Jun 2009 21:44:53 +0200 (CEST) (envelope-from marius) Date: Wed, 3 Jun 2009 21:44:53 +0200 From: Marius Strobl To: Eygene Ryabinkin Message-ID: <20090603194453.GA43137@alchemy.franken.de> References: <20090602222445.2F6017302F@freebsd-current.sentex.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: current@freebsd.org, sparc64@freebsd.org, rwatson@freebsd.org, FreeBSD Tinderbox , kmacy@freebsd.org Subject: Re: [head tinderbox] failure on sparc64/sun4v X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jun 2009 20:05:48 -0000 On Wed, Jun 03, 2009 at 01:54:30PM +0400, Eygene Ryabinkin wrote: > Wed, Jun 03, 2009 at 09:25:38AM +0400, Eygene Ryabinkin wrote: > > Tue, Jun 02, 2009 at 06:24:45PM -0400, FreeBSD Tinderbox wrote: > > > cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/sun4v/sun4v/machdep.c > > > /src/sys/sun4v/sun4v/machdep.c:192: error: size of array '__assert192' is negative > > > *** Error code 1 > > > > > > Stop in /obj/sun4v/src/sys/LINT. > > > > This seems to be related to the recent NETISR changes, namely, the > > addition of the pc_netisr member to the struct pcpu: > > http://svn.freebsd.org/viewvc/base/head/sys/sys/pcpu.h?r1=187679&r2=193219&diff_format=u > > > > I am not sure how large (void *) is on sun4v, but it seems to me > > that it is 4 bytes long, so PCPU_MD_FIELDS_PAD inside sun4v/include/pcpu.h > ^^^^^^^^^^^^ > Sorry, eight bytes long: wrote 4, but really meant 8 ;)) > > > should be compensated for this change. Something like > > ----- > > #ifdef KTR > > #define PCPU_MD_FIELDS_PAD (3 - (PCPU_NAME_LEN + 7) / 8) > > #else > > #define PCPU_MD_FIELDS_PAD 3 > > #endif > > ----- > > though I am not very sure about KTR's case. > > KTR's case seems to be wrong for PCPU_NAME_LEN larger than 24 bytes. > Just now we won't be able to reach this with the current definition > for PCPU_NAME_LEN, but some day (N - (PCPU_NAME_LEN + 7)/8) can > become negative and that's bad. If it actually becomes negative the build should break again, which IMO is sufficient protection. > > The attached patch should fix this (although I have no sun4v to test > on, so take it with a grain of salt). I think this is overengineered, especially if not also adjusting the padding for other macros which may change the size of both MD and MI parts of struct pcpu. > > By the way, having looked at sys/sys/pcpu.h, I see that there are parts > of 'struct pcpu' that depend on the KTR_PERCPU being defined and they > are never compensated with padding in PCPU_MD_FIELDS for sun4v. Is > KTR_PERCPU constant for sun4v (inexisting or defined everytime) or I am > missing something? > It's just not taken into account but AFAICT also dead code. Marius