re: CVS commit: src/sys/rump/librump/rumpkern
> On Mon, Jun 14, 2010 at 09:40:37AM -0600, M. Warner Losh wrote: > > On i386, that's true. amd64 expands to '0', as does sun3. This makes > > the first one true. The second one, i386 expands to '1', so the > > second one would be false. > > Arguably we shouhld fix our gcc to only define "__i386__", not "i386", > which conflicts with the user namespace... i agree. i was going to reply to an earlier message on this that it was the kernel Makefile's that define $MACHINE, but upon looking at them i noticed that only a few do, and that i486--netbsdelf-gcc defines "i386" all the time so i didn't send any email. we should audit all of our gcc configs and kernel configs to deal. .mrg.
Re: CVS commit: src/sys/rump/librump/rumpkern
In message: <20100615052154.gb16...@netbsd.org> David Holland writes: : On Mon, Jun 14, 2010 at 09:40:37AM -0600, M. Warner Losh wrote: : > On i386, that's true. amd64 expands to '0', as does sun3. This makes : > the first one true. The second one, i386 expands to '1', so the : > second one would be false. : : Arguably we shouhld fix our gcc to only define "__i386__", not "i386", : which conflicts with the user namespace... True, but doing so would likely break applications that have depended on this define. Which is worse? Warner
Re: CVS commit: src/sys/rump/librump/rumpkern
On Mon, Jun 14, 2010 at 09:40:37AM -0600, M. Warner Losh wrote: > On i386, that's true. amd64 expands to '0', as does sun3. This makes > the first one true. The second one, i386 expands to '1', so the > second one would be false. Arguably we shouhld fix our gcc to only define "__i386__", not "i386", which conflicts with the user namespace... -- David A. Holland dholl...@netbsd.org
Re: CVS commit: src/tests/util
On Mon, Jun 14, 2010 at 06:57:21PM +0300, Antti Kantee wrote: > > So I was meaning to ask: why does "anita test" not install /usr/share, > > Dunno. I'm guessing "it's not necessary to fullfill anita's mission". Well, I guess, but I would have expected it to install everything by default, as otherwise there could in theory be a problem with the sets it leaves off... > Maybe eventually we'll have configuration file support for selecting sets, > but volunteer-project-etc-yaddayadda. right > > and what else is it randomly missing that other tests might > > unknowingly depend on? > > First of all, tests should be deterministic, so using something such as > "words" which might change from underneath the test is not recommended. > Admittedtly in this case the probability that words would shrink so much > as to make the test non-effective is quite low, but since deterministic > input can be generated just as easily, there is no excuse for not > doing so. Granted. > Second, working on the definition of "randomly missing". Stay tuned. I think it's hiding somewhere near the definition of "random number". Nine is a very random number. (http://www.dilbert.com/2001-10-25/) -- David A. Holland dholl...@netbsd.org
Re: CVS commit: src/sys/arch/m68k/conf
On Sun, 6 Jun 2010, matthew green wrote: Module Name:src Committed By: mrg Date: Sun Jun 6 04:51:33 UTC 2010 Modified Files: src/sys/arch/m68k/conf: files.m68k Log Message: fix PR 6724 - convert m68k options to defflag's. this means that M680[12346] are now available from opt_m68k_arch.h. FPSP meantioned in the PR has already been fixed, and i could not find any more. i built these kernels to ensure i did not break their builds: Well, they might build, but that doesn't mean they will run :) This change breaks setting the cc and asm flags based on the kernel options. In my case, I was compiling for my 68060, and since none of the cpu types was passed to the Makefile, it generated code a multiply that is not supported on the 68060, and my kernel crashed with an unimplemented instruction trap. After looking at uvm_pctparam_set() on both my new kernel and a working one, I noticed the difference in how the multiply was done. Checking the build of the bad kernel and a log from a previous build, I found that the -m68020-60 option was missing. After a hunt to see where that was to come from (src/sys/arch/m68k/Makefile.cmachflags), I found that IDENT no longer generated the cpu type flags from the config file. This means we have to go back to explicitly setting the build options in the config files in order to generate the correct code, or set the appropriate build options outside the kernel build. -- Michael L. Hitchmhi...@montana.edu Computer Consultant Information Technology Center Montana State UniversityBozeman, MT USA
Re: CVS commit: src/tests/util
On Sun Jun 13 2010 at 00:36:18 +, David Holland wrote: > On Sat, Jun 12, 2010 at 01:15:02PM +, Antti Kantee wrote: > > Modified Files: > >src/tests/util: t_sort.sh > > > > Log Message: > > Make the test work on an installation without sharesrc. > > So I was meaning to ask: why does "anita test" not install /usr/share, Dunno. I'm guessing "it's not necessary to fullfill anita's mission". Maybe eventually we'll have configuration file support for selecting sets, but volunteer-project-etc-yaddayadda. > and what else is it randomly missing that other tests might > unknowingly depend on? First of all, tests should be deterministic, so using something such as "words" which might change from underneath the test is not recommended. Admittedtly in this case the probability that words would shrink so much as to make the test non-effective is quite low, but since deterministic input can be generated just as easily, there is no excuse for not doing so. Second, working on the definition of "randomly missing". Stay tuned.
Re: CVS commit: src/sys/rump/librump/rumpkern
In message: <20100614083424.gc16...@cs.hut.fi> Antti Kantee writes: : On Mon Jun 14 2010 at 07:00:05 +, David Holland wrote: : > On Sun, Jun 13, 2010 at 03:17:02PM +, Antti Kantee wrote: : > > Fix previous in emul.c -- only numbers are operands for cpp comparisons. : > > Apparently non-numbers logically produce arch-dependent behaviour. : > : > Not at all. : > : > C99 6.10.1 #4: : > : > [...] After all replacements due to macro expansion and the defined : > unary operator have been performed, all remaining identifiers : > (including those lexically identical to keywords) are replaced with : > the pp-number 0, and then each preprocessing token is converted into : > a token. The resulting tokens compose the controlling constant : > expression which is evaluated according to the rules of 6.6. [...] : : So, you being the person who attempted to write cpp with sed, what : comparison does "amd64 == sun3" actually result in? What about : "i386 == sun3" (the former returned true, the latter didn't). On i386, that's true. amd64 expands to '0', as does sun3. This makes the first one true. The second one, i386 expands to '1', so the second one would be false. Warner
Re: CVS commit: src/sys/rump/librump/rumpkern
On Mon, Jun 14, 2010 at 12:27:43PM +0300, Antti Kantee wrote: > How can you tell what they end up as? I can only see that the line > wrapped in the "#if" is missing from output of cc -E (still on/targetting > i386). Well, knowing the standard (as David cited) and checking with cc -dM -E - < /dev/null what is defined on your arch you can make an educated guess. But sure, you can't realy tell whether someone did a "#define sun3 1" somewhere in the code. Martin
Re: CVS commit: src/sys/rump/librump/rumpkern
On Mon Jun 14 2010 at 09:17:43 +, David Holland wrote: > On Mon, Jun 14, 2010 at 11:34:24AM +0300, Antti Kantee wrote: > > So, you being the person who attempted to write cpp with sed, what > > comparison does "amd64 == sun3" actually result in? What about > > "i386 == sun3" (the former returned true, the latter didn't). > > What were you compiling on? Whether it should or not, our i386 gcc > predefines "i386", so you probably got 0 == 0 and 1 == 0 respectively. Ah, ok, now I see what happened. thanks
Re: CVS commit: src/sys/rump/librump/rumpkern
On Mon Jun 14 2010 at 11:13:23 +0200, Martin Husemann wrote: > On Mon, Jun 14, 2010 at 11:34:24AM +0300, Antti Kantee wrote: > > So, you being the person who attempted to write cpp with sed, what > > comparison does "amd64 == sun3" actually result in? What about > > "i386 == sun3" (the former returned true, the latter didn't). > > For me both end up as 0==0 and return true ;-) How can you tell what they end up as? I can only see that the line wrapped in the "#if" is missing from output of cc -E (still on/targetting i386).
Re: CVS commit: src/sys/rump/librump/rumpkern
On Mon, Jun 14, 2010 at 11:34:24AM +0300, Antti Kantee wrote: > So, you being the person who attempted to write cpp with sed, what > comparison does "amd64 == sun3" actually result in? What about > "i386 == sun3" (the former returned true, the latter didn't). What were you compiling on? Whether it should or not, our i386 gcc predefines "i386", so you probably got 0 == 0 and 1 == 0 respectively. -- David A. Holland dholl...@netbsd.org
Re: CVS commit: src/sys/rump/librump/rumpkern
On Mon, Jun 14, 2010 at 11:34:24AM +0300, Antti Kantee wrote: > So, you being the person who attempted to write cpp with sed, what > comparison does "amd64 == sun3" actually result in? What about > "i386 == sun3" (the former returned true, the latter didn't). For me both end up as 0==0 and return true ;-) Martin
Re: CVS commit: src/sys/rump/librump/rumpkern
On Mon Jun 14 2010 at 07:00:05 +, David Holland wrote: > On Sun, Jun 13, 2010 at 03:17:02PM +, Antti Kantee wrote: > > Fix previous in emul.c -- only numbers are operands for cpp comparisons. > > Apparently non-numbers logically produce arch-dependent behaviour. > > Not at all. > > C99 6.10.1 #4: > > [...] After all replacements due to macro expansion and the defined > unary operator have been performed, all remaining identifiers > (including those lexically identical to keywords) are replaced with > the pp-number 0, and then each preprocessing token is converted into > a token. The resulting tokens compose the controlling constant > expression which is evaluated according to the rules of 6.6. [...] So, you being the person who attempted to write cpp with sed, what comparison does "amd64 == sun3" actually result in? What about "i386 == sun3" (the former returned true, the latter didn't).
Re: CVS commit: src/sys/rump/librump/rumpkern
On Sun, Jun 13, 2010 at 03:17:02PM +, Antti Kantee wrote: > Fix previous in emul.c -- only numbers are operands for cpp comparisons. > Apparently non-numbers logically produce arch-dependent behaviour. Not at all. C99 6.10.1 #4: [...] After all replacements due to macro expansion and the defined unary operator have been performed, all remaining identifiers (including those lexically identical to keywords) are replaced with the pp-number 0, and then each preprocessing token is converted into a token. The resulting tokens compose the controlling constant expression which is evaluated according to the rules of 6.6. [...] -- David A. Holland dholl...@netbsd.org
