Date: Sat, 30 May 2015 13:46:09 +1000 (EST) From: Bruce Evans <brde@optusnet.com.au> To: Brooks Davis <brooks@freebsd.org> Cc: Bruce Evans <brde@optusnet.com.au>, src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: Re: svn commit: r283671 - head/sys/sys Message-ID: <20150530125541.J971@besplex.bde.org> In-Reply-To: <20150529203546.GN38480@spindle.one-eyed-alien.net> References: <201505282206.t4SM66Xj090527@svn.freebsd.org> <20150529154745.F900@besplex.bde.org> <20150529203546.GN38480@spindle.one-eyed-alien.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 29 May 2015, Brooks Davis wrote: > On Fri, May 29, 2015 at 05:40:16PM +1000, Bruce Evans wrote: >> On Thu, 28 May 2015, Brooks Davis wrote: >> >>> Log: >>> Revert r102953 >>> >>> The bitfile padding was always unallocated on real-world FreeBSD systems and >>> depended on the assumption that (abs(sizeof(long) - sizeof(char*)) <= 32). >> >> Actually, it was bit-field padding that depended on the assumption that >> (abs(sizeof(long) - sizeof(char*)) <= CHAR_BIT * sizeof(int). >> >> It did work under this assumption, and was needed on non-real-world FreeBSD >> systems with correctly-sized longs. Why break it? Actually, it only worked under the assumption that sizeof(long) >= sizeof(char *) && <the above>. It was nonsense when sizeof(char *) > sizeof(long). Then there is no way to unpad the char * field to reduce the size, and no need for any padding or unpadding to change the size since the char * field has the same size as the union (under additional assumptions about alignment). The nonsense actually negatived the (negative) unpadding to get positive padding that compiled. > It doesn't work on CHERI where pointers are 64, 128 or 256 bits > depending on the compilation mode and hardware type (in the latter two > cases they are not arithmetic types). That was a nonsense case. If you just fix the old code to use the correct padding of 0 in this case, CHERI wouldn't notice the problem. > If this was something we were worried about in practice, forcing the > alignment of n_name and n_type to max(sizeof(long), sizeof(char *)) > would accomplish the padding in a way that works for any compiler we > care about and irrespective of size. This would defeat care taken elsewhere to use only C90 features in headers. But __aligned() is already used a lot. Since it affects semantics, it is correctly not defined as nothing, except in the broken lint case. Newer arches probably shouldn't support aout. Then it is another bug to include aout headers. But the nlist_aout.h header is really common for elf and aout -- the only aout-only part of it is the union half of the ifdef. It is in much better shape than the documentation for nlist(3) -- nlist() is now used mainly for elf, but is only documented for aout. Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20150530125541.J971>