Date: Fri, 19 Apr 1996 13:37:59 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: phk@critter.tfs.com (Poul-Henning Kamp) Cc: terry@lambert.org, kuku@gilberto.physik.rwth-aachen.de, freebsd-current@freefall.freebsd.org Subject: Re: gzipped executables Message-ID: <199604192037.NAA08918@phaeton.artisoft.com> In-Reply-To: <724.829944911@critter.tfs.com> from "Poul-Henning Kamp" at Apr 19, 96 08:15:11 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> Terry, come up with a patch, or stop this nonsense. > there is no self-modifying code involved... > > Christph: No I'm sorry I don't have time. It shouldn't be that hard > though, if you have cvs try to find out when it broke, that would > help a lot. > > Poul-Henning My root assumptions as to the cause may be incorrect. Flushing the cache queue with 32 NOP's, nevertheless, works, even if *my* reason isn't *the* reason. Feel free to come up with another explanation, or feel free to kludge the NOP's before the jmp and accept the fact that it works without a satisfactory (to you) explanation of *why* it works. If I'm correct, I expect it to "fix" a 486 with 16 NOP's but not a Pentium (and this has been observed in testing on my machines), and to fix a Pentium and a 486 with 32 NOP's (which also works in testing on my machines). Admittedly, my theory is only a theory which fits all known facts (which, I willingly admit, doesn't necessarily make it true). Apply my "fix" from the previous discussion of -current on this same topic... quoted "fix" because I believe it's a kludge around what is really a bug in the decompressor. Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199604192037.NAA08918>