Date: Wed, 17 Oct 2001 16:42:31 +1000 (EST) From: Bruce Evans <bde@zeta.org.au> To: "Dorr H. Clark" <dclark@applmath.scu.edu> Cc: <freebsd-bugs@FreeBSD.ORG> Subject: Re: ansi bug in vm_mmap.c & nspvar.h - are there more of these? Message-ID: <20011017162151.A14904-100000@delplex.bde.org> In-Reply-To: <Pine.GHP.4.21.0110161003380.5965-100000@hpux36.dc.engr.scu.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 16 Oct 2001, Dorr H. Clark wrote: > In sys/vm/vm_mmap.c the functions mmap(), munmap(), and madvise() > all have the same problem in release 4.4 and at the top version. > > The problem is the code block of the form: > > #ifndef i386 > if (VM_MIN_ADDRESS ... etc. > return (EINVAL); > #endif > > In the kernel compilations, -ansi is thrown in all 4.x > releases. One of the effects of -ansi is to suppress > the gcc ansi intrusion of the architecture compiler flags, > so for example the equivalent of -Di386 is not thrown > for kernel builds. > > As a result, the three code blocks described above > are actually ENABLED on all platforms. I fixed this many years ago, but haven't got around to committing the fix, partly because the bug has no effect (except for causing minor pessimizations if the code is compiled without optimization). It could only affect i386's, but on i386's VM_MIN_ADDRESS is 0, so the all the code in the ifdef is dead. gcc -O optimizes it away at compile time. gcc -O0 generates runtime code that does nothing. > There is an immediate question of what to do about > these code blocks. If the string i386 is converted > to __i386__, the behavior will change on the x86 > since the code inside the define will now be suppressed. I just changed them to __i386__, but the correct fix is probably just to remove the ifdefs. > Another example of this problem is in sys/dev/nsp/nspvar.h > at the very bottom of the file. The macro SOFT_INTR_REQUIRED > is behind an #if defined(i386) which is suppressed in > the kernel build because of -ansi. This causes > SOFT_INTR_REQUIRED to be defined into nothing on all > architectures. This looks like a real bug. However, the interface used by this macro (softintr()) doesn't really exist in FreeBSD, especially for i386's. I think it is a NetBSD thing. It exists in the powerpc headers and in some compatibilty code. > But I have a broader question: if the -ansi flag is > withdrawn from the kernel builds, how many other > compilations will change, and what is the best way > for these to be found? Compile LINT with and without -ansi and compare the results (complain about sources that ensure irreproducible results using $TIME :-). I used this to find most of the "#ifdef i386"'s when I turned on -ansi. > Finally, should I fill out a bug report on this? Sure, for any significant differences. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20011017162151.A14904-100000>