Re: Adding 'realclean' target to /usr/src/Makefile
On Sun, Feb 15, 2004 at 02:42:07AM -0500, Garance A Drosihn wrote: It occurs to me that the simple, reliable solution to this is to add a 'realclean' target to /usr/src/Makefile, such as: I don't have a problem with this. However, on a related but somewhat separate note: It would be helpful if it were pointed out in documentation somewhere that the path to the compile and source directories, when doing NFS kernel installs, has to be identical to those which were in effect on the build box due to the treatment of MAKEOBJDIRPREFIX during the modules build (and subsequent modules/* path creation). BMS ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Adding 'realclean' target to /usr/src/Makefile
On Sun, Feb 15, 2004 at 09:20:56AM + I heard the voice of Bruce M Simpson, and lo! it spake thus: It would be helpful if it were pointed out in documentation somewhere that the path to the compile and source directories, when doing NFS kernel installs, has to be identical to those which were in effect on the build box due to the treatment of MAKEOBJDIRPREFIX during the modules build (and subsequent modules/* path creation). And, last time I tried it (which admittedly was a long time ago, so grab your salt grainer), the same applied to world builds too. -- Matthew Fuller (MF4839) | [EMAIL PROTECTED] Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ The only reason I'm burning my candle at both ends, is because I haven't figured out how to light the middle yet ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Adding 'realclean' target to /usr/src/Makefile
Bruce M Simpson wrote: On Sun, Feb 15, 2004 at 02:42:07AM -0500, Garance A Drosihn wrote: It occurs to me that the simple, reliable solution to this is to add a 'realclean' target to /usr/src/Makefile, such as: I don't have a problem with this. However, on a related but somewhat separate note: It would be helpful if it were pointed out in documentation somewhere that the path to the compile and source directories, when doing NFS kernel installs, has to be identical to those which were in effect on the build box due to the treatment of MAKEOBJDIRPREFIX during the modules build (and subsequent modules/* path creation). BMS I believe this is mentioned in the development(7) man page. But I do not believe it is not mentioned in the relevant handbook section. And this (very useful) man page is never mentioned in the handbook anywhere. I found it by accident one day when looking for something else. Richard Coleman [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Adding 'realclean' target to /usr/src/Makefile
In message: [EMAIL PROTECTED]
Garance A Drosihn [EMAIL PROTECTED] writes:
: realclean :
: rm -Rf ${.OBJDIR}/*
I'd make that be more like:
realclean :
@chflags -R 0 ${.OBJDIR}/*
@rm -Rf ${.OBJDIR}/*
since sometimes you wind up files that have flags set on them. I once
looked into hacking rm to do that in one step, but couldn't figure out
a way to do it race free and punted. There was no notion of a
funlink. this is conceptually as close as I got:
fd = open(path, O_RDRW); /*1*/
fchflags(fd, 0);
unlink(path); /*2*/
which races between /*1*/ and /*2*/.
If you can tolerate errors in the output, the following is faster
because the chflags has lots less work to do:
realclean :
@rm -Rf ${.OBJDIR}/*
@chflags -R 0 ${.OBJDIR}/*
@rm -Rf ${.OBJDIR}/*
Warner
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Adding 'realclean' target to /usr/src/Makefile
In message: [EMAIL PROTECTED] Bruce M Simpson [EMAIL PROTECTED] writes: : It would be helpful if it were pointed out in documentation somewhere : that the path to the compile and source directories, when doing NFS : kernel installs, has to be identical to those which were in effect on : the build box due to the treatment of MAKEOBJDIRPREFIX during the modules : build (and subsequent modules/* path creation). Remove the word kernel. It has to be identical for *ALL* installs. *OR* you have to play games with symbolic links (which is what Timing Solutions does for their chroot build environments). Warner ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Maestro-2E no workee in 5.2.1-RC2
Hello, I recently upgraded from FreeBSD 5.1 to 5.2.1-RC2 because I needed support for my Atheros-based wifi card. However, my Maestro-2E sound card does not function under 5.2.1, whereas it worked fine with 5.1. For what it's worth, the machine is a Toshiba Portege 7020CT, and ACPI is (necessarily) disabled. Here is the kernel output that occurs when I run kldload snd_maestro: -- snip -- pcm0: ESS Technology Maestro-2E port 0xee00-0xeeff irq 11 at device 12.0 on pci0 pcm0: agg_rdcodec() RW_DONE timed out. pcm0: agg_rdcodec() PROGLESS timed out. pcm0: agg_rdcodec() RW_DONE timed out. pcm0: agg_wrcodec() PROGLESS timed out. pcm0: agg_rdcodec() PROGLESS timed out. pcm0: agg_rdcodec() RW_DONE timed out. pcm0: agg_wrcodec() PROGLESS timed out. pcm0: agg_rdcodec() PROGLESS timed out. pcm0: agg_rdcodec() RW_DONE timed out. pcm0: agg_wrcodec() PROGLESS timed out. pcm0: agg_rdcodec() PROGLESS timed out. pcm0: agg_rdcodec() RW_DONE timed out. pcm0: agg_wrcodec() PROGLESS timed out. pcm0: agg_rdcodec() PROGLESS timed out. pcm0: agg_rdcodec() RW_DONE timed out. pcm0: agg_wrcodec() PROGLESS timed out. pcm0: agg_rdcodec() PROGLESS timed out. pcm0: agg_rdcodec() RW_DONE timed out. pcm0: agg_wrcodec() PROGLESS timed out. pcm0: agg_rdcodec() PROGLESS timed out. pcm0: agg_rdcodec() RW_DONE timed out. pcm0: agg_wrcodec() PROGLESS timed out. pcm0: agg_rdcodec() PROGLESS timed out. pcm0: agg_rdcodec() RW_DONE timed out. pcm0: agg_wrcodec() PROGLESS timed out. pcm0: agg_rdcodec() PROGLESS timed out. pcm0: agg_rdcodec() RW_DONE timed out. pcm0: agg_wrcodec() PROGLESS timed out. pcm0: agg_rdcodec() PROGLESS timed out. pcm0: agg_rdcodec() RW_DONE timed out. pcm0: agg_wrcodec() PROGLESS timed out. pcm0: Asahi Kasei AK4540 AC97 Codec pcm0: agg_rdcodec() PROGLESS timed out. pcm0: agg_rdcodec() RW_DONE timed out. pcm0: ac97 codec reports dac not ready pcm0: agg_wrcodec() PROGLESS timed out. pcm0: agg_wrcodec() PROGLESS timed out. -- snip -- Any help/suggestions would be greatly appreciated. Joseph Dunn ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Adding 'realclean' target to /usr/src/Makefile
On Sun, Feb 15, 2004 at 10:19:00AM -0700, M. Warner Losh wrote:
In message: [EMAIL PROTECTED]
Garance A Drosihn [EMAIL PROTECTED] writes:
: realclean :
: rm -Rf ${.OBJDIR}/*
I'd make that be more like:
realclean :
@chflags -R 0 ${.OBJDIR}/*
@rm -Rf ${.OBJDIR}/*
since sometimes you wind up files that have flags set on them.
Sounds like a bug to me. Do you have examples?
If you can tolerate errors in the output, the following is faster
because the chflags has lots less work to do:
realclean :
@rm -Rf ${.OBJDIR}/*
@chflags -R 0 ${.OBJDIR}/*
@rm -Rf ${.OBJDIR}/*
Since there should be no flags on files in the object directory in
principle, the errors are probably useful to track down where these
get set.
In any case: I think a realclean target based on a recursive rm is
generally useful. Adding a chflags in there makes it more foolproof
and thus ideal for UPDATING and other user oriented documentation.
--
Marcel Moolenaar USPA: A-39004 [EMAIL PROTECTED]
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Adding 'realclean' target to /usr/src/Makefile
In message: [EMAIL PROTECTED]
Marcel Moolenaar [EMAIL PROTECTED] writes:
: On Sun, Feb 15, 2004 at 10:19:00AM -0700, M. Warner Losh wrote:
: In message: [EMAIL PROTECTED]
: Garance A Drosihn [EMAIL PROTECTED] writes:
: : realclean :
: : rm -Rf ${.OBJDIR}/*
:
: I'd make that be more like:
:
: realclean :
: @chflags -R 0 ${.OBJDIR}/*
: @rm -Rf ${.OBJDIR}/*
:
: since sometimes you wind up files that have flags set on them.
:
: Sounds like a bug to me. Do you have examples?
libc.so.4 in the installed libraries in MAKEOBJDIRPREFIX if you have a
really old obj tree. This is supposed to be foolproof, no?
: If you can tolerate errors in the output, the following is faster
: because the chflags has lots less work to do:
:
: realclean :
: @rm -Rf ${.OBJDIR}/*
: @chflags -R 0 ${.OBJDIR}/*
: @rm -Rf ${.OBJDIR}/*
:
: Since there should be no flags on files in the object directory in
: principle, the errors are probably useful to track down where these
: get set.
:
: In any case: I think a realclean target based on a recursive rm is
: generally useful. Adding a chflags in there makes it more foolproof
: and thus ideal for UPDATING and other user oriented documentation.
Yup.
Warner
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Adding 'realclean' target to /usr/src/Makefile
At 10:19 AM -0700 2/15/04, M. Warner Losh wrote:
In message: [EMAIL PROTECTED]
Garance A Drosihn [EMAIL PROTECTED] writes:
: realclean :
: rm -Rf ${.OBJDIR}/*
I'd make that be more like:
realclean :
@chflags -R 0 ${.OBJDIR}/*
@rm -Rf ${.OBJDIR}/*
If you can tolerate errors in the output, the following is
faster because the chflags has lots less work to do:
realclean :
@rm -Rf ${.OBJDIR}/*
@chflags -R 0 ${.OBJDIR}/*
@rm -Rf ${.OBJDIR}/*
The more foolproof/reliable we can make it for everybody, the
more I like it. I'll see your chflags, and add one redirection
of stderr so the user won't see errors that we don't really
care about:
realclean :
@rm -Rf ${.OBJDIR}/* 2/dev/null
@chflags -R 0 ${.OBJDIR}/*
@rm -Rf ${.OBJDIR}/*
Any errors that showed up on the first 'rm' should also show up
on the second 'rm', so we shouldn't really lose any useful info.
I might also try wrapping the second two commands in an 'if', so
they will be executed only if there's still something left over
after the first 'rm'.
--
Garance Alistair Drosehn= [EMAIL PROTECTED]
Senior Systems Programmer or [EMAIL PROTECTED]
Rensselaer Polytechnic Instituteor [EMAIL PROTECTED]
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD 5.2 v/s FreeBSD 4.9 MFLOPS performance (gcc3.3.3 v/s gcc2.9.5)
Alexandr Kovalenko [EMAIL PROTECTED] writes: Could you please explain me this? Result is fully reproduceable. Please note, that the only difference is the output file name. Even resulting files match bit-to-bit. [...] Definitely some kind of alignment problem, but it only shows up at some optimization levels and not others. [EMAIL PROTECTED] ~/src/flops% ll f*s lrwxr-xr-x 1 des des 5 Feb 15 21:34 fflops@ - flops lrwxr-xr-x 1 des des 5 Feb 15 21:06 flops@ - flops lrwxr-xr-x 1 des des 5 Feb 15 21:06 lops@ - flops lrwxr-xr-x 1 des des 5 Feb 15 21:08 ffflops@ - flops lrwxr-xr-x 1 des des 5 Feb 15 21:08 fflops@ - flops lrwxr-xr-x 1 des des 5 Feb 15 21:08 flops@ - flops lrwxr-xr-x 1 des des 5 Feb 15 21:03 lops@ - flops lrwxr-xr-x 1 des des 5 Feb 15 21:03 ffflops@ - flops lrwxr-xr-x 1 des des 5 Feb 15 21:02 fflops@ - flops lrwxr-xr-x 1 des des 5 Feb 15 21:02 flops@ - flops lrwxr-xr-x 1 des des 5 Feb 15 21:02 lops@ - flops lrwxr-xr-x 1 des des 5 Feb 15 21:02 ffflops@ - flops lrwxr-xr-x 1 des des 5 Feb 15 21:02 fflops@ - flops lrwxr-xr-x 1 des des 5 Feb 15 21:02 flops@ - flops lrwxr-xr-x 1 des des 5 Feb 15 21:02 lops@ - flops lrwxr-xr-x 1 des des 5 Feb 15 21:02 ffflops@ - flops lrwxr-xr-x 1 des des 5 Feb 15 21:02 fflops@ - flops -rwxr-xr-x 1 des des 20875 Feb 15 21:05 flops* lrwxr-xr-x 1 des des 5 Feb 15 20:55 flucking-slow-flops@ - flops [EMAIL PROTECTED] ~/src/flops% cc -DUNIX -o flops flops.c [EMAIL PROTECTED] ~/src/flops% for f in f*s ; do ./$f | grep MFLOPS.1. ; done MFLOPS(1) = 386.3844 MFLOPS(1) = 365.9330 MFLOPS(1) = 364.1425 MFLOPS(1) = 366.6225 MFLOPS(1) = 389.3461 MFLOPS(1) = 377.1758 MFLOPS(1) = 354.1909 MFLOPS(1) = 356.5961 MFLOPS(1) = 371.7964 MFLOPS(1) = 366.3965 MFLOPS(1) = 407.1590 MFLOPS(1) = 375.0376 MFLOPS(1) = 353.9504 MFLOPS(1) = 394.1439 MFLOPS(1) = 134.2436 MFLOPS(1) = 148.3984 MFLOPS(1) = 390.5495 MFLOPS(1) = 373.4338 MFLOPS(1) = 341.5228 [EMAIL PROTECTED] ~/src/flops% cc -DUNIX -O0 -o flops flops.c [EMAIL PROTECTED] ~/src/flops% for f in f*s ; do ./$f | grep MFLOPS.1. ; done MFLOPS(1) = 392.9511 MFLOPS(1) = 361.4795 MFLOPS(1) = 407.0004 MFLOPS(1) = 368.2120 MFLOPS(1) = 355.9699 MFLOPS(1) = 378.2740 MFLOPS(1) = 372.4568 MFLOPS(1) = 339.8898 MFLOPS(1) = 367.3776 MFLOPS(1) = 379.0460 MFLOPS(1) = 363.5696 MFLOPS(1) = 379.5704 MFLOPS(1) = 390.2681 MFLOPS(1) = 382.3747 MFLOPS(1) = 175.9839 MFLOPS(1) = 131.9588 MFLOPS(1) = 379.4554 MFLOPS(1) = 385.6065 MFLOPS(1) = 363.8399 [EMAIL PROTECTED] ~/src/flops% cc -DUNIX -O -o flops flops.c [EMAIL PROTECTED] ~/src/flops% for f in f*s ; do ./$f | grep MFLOPS.1. ; done MFLOPS(1) = 438.2079 MFLOPS(1) = 445.7388 MFLOPS(1) = 143.9707 MFLOPS(1) = 152.9320 MFLOPS(1) = 420.0060 MFLOPS(1) = 450.3305 MFLOPS(1) = 176.8822 MFLOPS(1) = 177.4155 MFLOPS(1) = 453.1921 MFLOPS(1) = 463.7040 MFLOPS(1) = 431.8273 MFLOPS(1) = 440.2074 MFLOPS(1) = 457.4747 MFLOPS(1) = 430.3638 MFLOPS(1) = 438.6455 MFLOPS(1) = 436.4352 MFLOPS(1) = 403.4691 MFLOPS(1) = 429.3843 MFLOPS(1) = 166.5295 [EMAIL PROTECTED] ~/src/flops% cc -DUNIX -O2 -o flops flops.c [EMAIL PROTECTED] ~/src/flops% for f in f*s ; do ./$f | grep MFLOPS.1. ; done MFLOPS(1) = 486.4274 MFLOPS(1) = 462.6540 MFLOPS(1) = 448.6820 MFLOPS(1) = 483.4713 MFLOPS(1) = 456.5398 MFLOPS(1) = 456.2924 MFLOPS(1) = 458.9312 MFLOPS(1) = 443.5167 MFLOPS(1) = 527.0580 MFLOPS(1) = 488.1867 MFLOPS(1) = 478.7150 MFLOPS(1) = 456.2584 MFLOPS(1) = 476.7231 MFLOPS(1) = 473.5441 MFLOPS(1) = 480.3434 MFLOPS(1) = 457.3464 MFLOPS(1) = 478.5790 MFLOPS(1) = 473.1698 MFLOPS(1) = 444.4634 [EMAIL PROTECTED] ~/src/flops% cc -DUNIX -O3 -o flops flops.c [EMAIL PROTECTED] ~/src/flops% for f in f*s ; do ./$f | grep MFLOPS.1. ; done MFLOPS(1) = 485.9121 MFLOPS(1) = 470.1213 MFLOPS(1) = 434.6227 MFLOPS(1) = 438.2213 MFLOPS(1) = 460.9863 MFLOPS(1) = 458.5821 MFLOPS(1) = 472.2775 MFLOPS(1)
Neat little, not so simple project...
We can compile our kernel with --test-coverage --profile-arcs to do basic-block profiling (see kernbb(8) and gcov(1)/gcc(1) docs.) Modify the code GCC inserts, so that it records if giant was held in one bit, and if not held in another, ie: if (giant) *counter_loc |= 1; else *counter_loc |= 2; Run your kernel for a few days. Use kernbb(8) to retrieve output. Produce graphics/statistics showing which code is Giant, which is giant free and which is mixed mode. Consider for instance the xterm unreadable font approach, and render the source files into pngs (a 800x660 png holds ten by ten standard pages without margins between) where you color the characters and lines by the result: black - not executed. red - executed with giant always yellow - executed with mixed giant holding green - never executed with giant. Brownie points: Get slashdotted when they discover you did it. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Neat little, not so simple project...
On Sun, Feb 15, 2004 at 10:32:30PM +0100, Poul-Henning Kamp wrote: Modify the code GCC inserts, so that it records if giant was held in one bit, and if not held in another, ie: if (giant) *counter_loc |= 1; else *counter_loc |= 2; Alternatively, modify the profiling code to or a global, like: *counter_loc |= global_state; And have each binary condition be represented by two bits. For giant this can be: NO_GIANT1 GIANT 2 To see if code is executed with interrupts enabled or disabled, one can add: INT_ENABLE 4 INT_DISABLE 8 and so forth. When we grab or release giant, we change the global state as follows: grab: global_state = (global_state ~NO_GIANT) | GIANT; rel:global_state = (global_state ~GIAN) | NO_GIANT; Likewise for other binary conditions. black - not executed. red - executed with giant always yellow - executed with mixed giant holding green - never executed with giant. The two bit per binary condition then gives the above: 0 = black 1 = green 2 = red 3 = yellow Just a thought, -- Marcel Moolenaar USPA: A-39004 [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Adding 'realclean' target to /usr/src/Makefile
At 10:19 AM -0700 2/15/04, M. Warner Losh wrote:
If you can tolerate errors in the output, the following is
faster because the chflags has lots less work to do:
realclean :
@rm -Rf ${.OBJDIR}/*
@chflags -R 0 ${.OBJDIR}/*
@rm -Rf ${.OBJDIR}/*
After some testing, I am planning to go with:
Index: Makefile
===
RCS file: /home/ncvs/src/Makefile,v
retrieving revision 1.292
diff -u -r1.292 Makefile
--- Makefile9 Dec 2003 02:08:19 - 1.292
+++ Makefile16 Feb 2004 00:29:54 -
@@ -104,6 +104,21 @@
.endif
#
+# This 'realclean' target is not included in TGTS, because it is not
+# a recursive target. All of the work for it is done right here.
+# The first 'rm' will usually remove all files and directories. If
+# it does not, then there are probably some files with chflags set.
+# Unset all special chflags, and try the 'rm' a second time.
+realclean :
+ -rm -Rf ${.OBJDIR}/* 2/dev/null
+ @-if [ `echo ${.OBJDIR}/*` != ${.OBJDIR}/* ] ; then \
+ echo chflags -R 0 ${.OBJDIR}/* ; \
+ chflags -R 0 ${.OBJDIR}/* ; \
+ echo rm -Rf ${.OBJDIR}/* ; \
+ rm -Rf ${.OBJDIR}/* ; \
+ fi
+
+#
# Handle the user-driven targets, using the source relative mk files.
#
= = = = = = = = = = = = = = = = = = = = = = = = = = = = = = =
If the first 'rm' works, the other two commands will not be
executed, and the user will only see the first 'rm'. If the
other two commands are executed, then the user will also see
echoed-versions of those commands before they are executed.
So, if there is some chflag'ed file in /usr/obj/..., what the
user sees is:
(330) keep-talking/root # make realclean
rm -Rf /usr/obj/usr/src/* 2/dev/null
*** Error code 1 (ignored)
chflags -R 0 /usr/obj/usr/src/*
rm -Rf /usr/obj/usr/src/*
--
Garance Alistair Drosehn= [EMAIL PROTECTED]
Senior Systems Programmer or [EMAIL PROTECTED]
Rensselaer Polytechnic Instituteor [EMAIL PROTECTED]
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD 5.2 v/s FreeBSD 4.9 MFLOPS performance (gcc3.3.3 v/s gcc2.9.5)
On Sunday 15 February 2004 12:46, Dag-Erling Smørgrav wrote: Alexandr Kovalenko [EMAIL PROTECTED] writes: Could you please explain me this? Result is fully reproduceable. Please note, that the only difference is the output file name. Even resulting files match bit-to-bit. [...] Definitely some kind of alignment problem, but it only shows up at some optimization levels and not others. I've tested the patch Dan mentioned before and the results were astonishing. Running the flops.c 1.2 program in a loop, lengthening the environment string by one byte each time, I get 8 successive runs of fast, then 8 successive runs of slow, where fast and slow vary between 650 and 990 mflops. With the patch, the performance is always 990, within a few percent. Should I commit this? RCS file: /big/ncvs/src/sys/kern/kern_exec.c,v retrieving revision 1.235 diff -u -w -r1.235 kern_exec.c --- kern_exec.c 28 Dec 2003 04:37:59 - 1.235 +++ kern_exec.c 11 Feb 2004 16:47:28 - @@ -1014,6 +1014,15 @@ */ vectp = (char **)(destp - (imgp-argc + imgp-envc + 2) * sizeof(char *)); + + /* +* Align stack to a multiple of 0x20. +* XXX vectp has the wrong type; we usually want a vm_offset_t; +* the suword() family takes a void *, but should take a vm_offset_t. +* XXX should align stack for signals too. +* XXX should do this more machine/compiler-independently. +*/ + vectp = (char **)(((vm_offset_t)vectp ~(vm_offset_t)0x1F) - 4); /* * vectp also becomes our initial stack base -- Where am I, and what am I doing in this handbasket? Wes Peters Softweyr LLC [EMAIL PROTECTED]http://softweyr.com/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
