From owner-freebsd-current@FreeBSD.ORG Fri Sep 5 01:40:33 2003 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E89CF16A4C0 for ; Fri, 5 Sep 2003 01:40:33 -0700 (PDT) Received: from heron.mail.pas.earthlink.net (heron.mail.pas.earthlink.net [207.217.120.189]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7921143FE3 for ; Fri, 5 Sep 2003 01:40:30 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from user-2ivfjg5.dialup.mindspring.com ([165.247.206.5] helo=mindspring.com) by heron.mail.pas.earthlink.net with asmtp (SSLv3:RC4-MD5:128) (Exim 3.33 #1) id 19vC8E-000609-00; Fri, 05 Sep 2003 01:39:51 -0700 Message-ID: <3F584B85.AAC3A11D@mindspring.com> Date: Fri, 05 Sep 2003 01:38:29 -0700 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Dan Nelson References: <20030904180448.021a1b6b.Alexander@Leidinger.net> <20030904162858.GI98381@dan.emsphone.com> <20030904225123.GB39916@dan.emsphone.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-ELNK-Trace: b1a02af9316fbb217a47c185c03b154d40683398e744b8a4cfb0bb7b6a149d3701f59d9ae9ad99a53ca473d225a0f487350badd9bab72f9c350badd9bab72f9c cc: Alexander Leidinger cc: current@freebsd.org Subject: Re: Question about genassym, locore.s and 0-sizedarrays(showstopper for an icc compiled kernel) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Sep 2003 08:40:34 -0000 Dan Nelson wrote: > I guess the correct question to be asking is "does the ELF format allow > 0-length symbols?" It does, according to my reading of it. They may have an issue with dead code removal or element aliasing. The way to find out would be to see what they emit for "[]"... 0 lenth, or 1? > If not, then gcc is generating invalid objects, and > genassym will have to be rewritten to not use them (maybe add one to > the array size, and have genassym.sh subtract it). If it does, then > genassym.c (sys/assym.h actually) is legal code. If Intel doesn't want > to change icc, we can still work around it, but there may be other code > that will break on icc just like assym.h. For example, an actual array of length 1 would mean you were screwed, since treating 1 as if it were 0 would treat that as zero, as well, and get the wrong answer. The real answer is that the code should probably use an array length of one, and then use the address of the array length 1 element, rather than the address of the object plus the size of the object, when it's trying to use the zero length array trick to glue data with the correct object alignment (according to the array type) onto the end of a structure, which is where most of this type of code comes from. Unfortunately, the genassym.sh is a special case; for it to work out if you changed the nature of the trick, the script would need to grow special knowledge of the symbols in question. That is probably going to be the answer in any case, if Intel is unwilling/unable to adopt the GCC-ism. Anecdote on "unable": At one point in time SEF had to deal with a compiler issue with the Microsoft C compiler used by SCO; it took code like this: char *hw = "Hello World!\n" + 6; and generated a data segment missing the "Hello ". When the code later did this: printf( "%s", hw - 6); It got the wrong answer. The problem was the MS compiler was unable to gerate a pseudo-symbol for the start of the data, and so had no way of taking the origina string, and allocating storage, with a static symbol offset +6 into the string. If Intel ICC makes an optimization based on pruning of actually zero-length element, or not aligning them to their type boundary, etc., it would take deep compiler voodoo to correct this. Hopefully, they do the right thing for "[]". -- Terry