Date: Mon, 13 Aug 2007 19:28:57 +0200 (MEST) From: Michiel Boland <michiel@boland.org> To: freebsd-sparc64@freebsd.org Subject: problem with user trap handlers in -CURRENT Message-ID: <Pine.GSO.4.64.0708131855050.5737@neerbosch.nijmegen.internl.net>
next in thread | raw e-mail | index | archive | help
This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. ---559023410-851401618-1187026137=:5737 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Hi. First, I would like to point out that I'm not at all an expert on sparc64, so please excuse me if I express myself a bit awkwardly. Now the problem. As you may or may not know, -CURRENT on sparc64 is broken in the sense that you can no longer ssh into a box that has UsePrivilegeSeparation yes in sshd_config. For more details, see http://lists.freebsd.org/pipermail/freebsd-current/2007-July/074569.html and http://lists.freebsd.org/pipermail/freebsd-current/2007-August/075996.html At the root of all this lies what I think is a fundamental problem with the way that alignment traps are handled. Attached you will find (unless the list software decides to eat it) a program that demonstrates what I mean. It creates a deliberate unaligned access trap. The idea is that the trap handler then emulates the load/store in software. This is done in __unaligned_fixup in src/lib/libc/sparc64/sys/__sparc_utrap_align.c. Unfortunately this emulation will not work if the trap is taken in the delay slot right after a return instruction, and the faulting address is on the stack of the procedure from which the processor just returned. This is because the contents of the stack are overwritten with a trap frame, at which point the emulation code will store an erroneous value. This is why the attached program outputs expected 37, got 0 instead of nothing, which it should do. (Surprise your friends: link traptest statically. It will then print a different value each time it is run. :) The assembler code generated by gcc looks like o2: save %sp, -208, %sp add %fp, 2019, %l0 add %l0, %i0, %l0 add %fp, 2027, %o0 call o3, 0 mov %l0, %o1 ldsb [%fp+2027], %g1 cmp %g1, 0 add %fp, 2019, %g1 movne %icc, %l0, %g1 return %i7+8 ldsw [%g1], %o0 <----- trap is taken here ^^^^^ this location will be overwritten by the trap frame I'm not sure how to work around this. I guess one solution would be to tell gcc not to generate these kinds of instruction combinations. But also I am wondering why FreeBSD attempts to emulate unaligned loads and stores in the first place. If I run traptest on Solaris, it crashes immediately with SIGBUS. I would have guessed it would do the same on FreeBSD. So I was a bit surprised that it ran at all. Is it not easier to just not handle unaligned traps at all and simply let programs crash? Or did someone already try this in the past, and too many things broke after that? Also I would assume that if you enforce that all memory access be aligned, and hence cut out all the (slow) emulation, you get at least a theoretical spead increase. Cheers Michiel ---559023410-851401618-1187026137=:5737 Content-Type: TEXT/PLAIN; charset=US-ASCII; name=traptest.c Content-Transfer-Encoding: BASE64 Content-ID: <Pine.GSO.4.64.0708131928570.5737@neerbosch.nijmegen.internl.net> Content-Description: Content-Disposition: attachment; filename=traptest.c I2luY2x1ZGUgPHN0ZGlvLmg+DQoNCiNpZm5kZWYgTUFHSUNfTlVNQkVSDQoj ZGVmaW5lIE1BR0lDX05VTUJFUiAzNw0KI2VuZGlmDQoNCmludCBvMihpbnQp Ow0KDQppbnQgbWFpbigpDQp7DQoJaW50IGkgPSBvMigxKTsNCg0KCWlmIChp ICE9IE1BR0lDX05VTUJFUikgew0KCQlmcHJpbnRmKHN0ZGVyciwgImV4cGVj dGVkICVkLCBnb3QgJWRcbiIsIE1BR0lDX05VTUJFUiwgaSk7DQoJCXJldHVy biAxOw0KCX0NCglyZXR1cm4gMDsNCn0NCg0Kdm9pZCBvMyhjaGFyICosIGNo YXIgKik7DQoNCmludCBvMihpbnQgb2Zmc2V0KQ0Kew0KCWludCAqcDsNCglj aGFyIGNbNF07DQoJY2hhciB0bXBbOF07DQoNCgkvKg0KICAgICAgICAgKiBv MyB3aWxsIHN0b3JlIHRoZSBtYWdpYyBudW1iZXIgaW4gKih0bXAgKyBvZmZz ZXQpDQoJICovDQoJbzMoYywgdG1wICsgb2Zmc2V0KTsNCgkvKg0KCSAqIG8z IHdpbGwgYWxzbyBtYWtlIGNbMF0gbm96ZXJvLCBzbyB3ZSBzaG91bGQgYWx3 YXlzDQoJICogcmV0dXJuICoodG1wICsgb2Zmc2V0KSwgdGhhdCBpcywgdGhl IG1hZ2ljIG51bWJlci4NCgkgKiBUaGlzIGNvbnN0cnVjdGlvbiBpcyBqdXN0 IGEgdHJpY2sgdG8gbWFrZSBnY2MNCgkgKiBlbWl0IHRoZSBjb3JyZWN0IGFz c2VtYmxlciBzdGF0ZW1lbnRzLg0KCSAqLw0KCXAgPSBjWzBdID8gKGludCAq KSAodG1wICsgb2Zmc2V0KSA6IChpbnQgKikgdG1wOw0KCXJldHVybiAqcDsN Cn0NCg0Kdm9pZCBvMyhjaGFyICpjcCwgY2hhciAqcykNCnsNCglpbnQgKmlw ID0gKGludCAqKSBzOw0KCSpjcCA9IDE7DQoJKmlwID0gTUFHSUNfTlVNQkVS Ow0KfQ0K ---559023410-851401618-1187026137=:5737--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.GSO.4.64.0708131855050.5737>