Date: Sun, 11 Apr 2010 11:24:17 +0200 From: Roman Divacky <rdivacky@freebsd.org> To: Bruce Evans <brde@optusnet.com.au> Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org Subject: Re: svn commit: r206424 - head/usr.bin/xlint/lint1 Message-ID: <20100411092417.GA37528@freebsd.org> In-Reply-To: <20100411175432.S10835@delplex.bde.org> References: <201004091521.o39FLBqx035856@svn.freebsd.org> <20100411175432.S10835@delplex.bde.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, Apr 11, 2010 at 07:16:12PM +1000, Bruce Evans wrote: > On Fri, 9 Apr 2010, Roman Divacky wrote: > > >Log: > > Rename the ALIGN macro to LINT_ALIGN so it does not clash with > > machine/param.h > > > > Bump the alignment to 16bytes because lint1 memory allocator is used for > > objects that require 16bytes alignment on amd64 (ie. val_t). This makes > > lint1 work when compiled with compiler(s) that use SSE for memcpy on > > amd64. > > (e.g. clang). > > This seems to be mostly backwards. xlint wants to use the system > ALIGN(), since it has no way of knowing the correct alignment. However, > the system might not supply ALIGN(), so it provided its own > probably-incorrect ALIGN() as a fallback. FreeBSD has a system ALIGN() > and it should have always been used. xlint get the includes correct > for this, though this is fragile. However2, the system ALIGN() on > amd64 doesn't know the correct alignment either (both essentially had > 64 bits hard-coded). Now xlint uses a different hard-coded alignment > (128 bits). so you suggest fixing the ALIGN on amd64? ie. to make it 128bit? > For a non-backwards fix, you need to follow the comment in xlint which > says ALIGN should go away [in xlint]. Other compilers might need a > working system ALIGN() in other places. I think only memory allocator > in xlint needs a working ALIGN() (just 1 instance). Perhaps the allocator > should just use malloc(). The only other uses of ALIGN() are in getbound(). > These seem to be all completely wrong. The all use ALIGN(1), where ALIGN() > is the host or hard-coded ALIGN() which gives maximal alignment and 1 is > the size of a char, where SALIGN(type), where SALIGN() is the source > ALIGN() which gives the (usually non-maximal) alignment of a type and > the `type' parameter must contain type info and not be just the size of > the type (certainly not the size of another type) since types of the same > size may have different alignment. SALIGN() is much more impossible to > write as a portable macro. the xlint allocator uses malloc and builds upon it. fixing this wont be trivial and I have no interest in it :(
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20100411092417.GA37528>