More on KEXTs & Altivec stack corruption
After doing more tests, I found some more information on the problem. I tested with building my KEXT with the -faltivec flag. None of the KEXT sources contains any vector code at this point. The final binary had some extra functions added to it: saveVEC, restVEC, saveVEC_vr11, and rest_VEC_vr10. This is not a big deal. However, in one of my functions in the middle of the binary, there are calls to save_VEC_vr11 and rest_VEC_vr10. I have no idea why these were inserted in this function and why only this function. Seeing this, I commented out all calls to this function in my KEXT and loaded it. The stack corruption panics did not occur. It seems these functions are the source of the problem. Here's the dumps of each function: saveVEC_vr11: 00022fd0 li r11,0xff40 00022fd4 stvx v20,r11,r0 00022fd8 li r11,0xff50 00022fdc stvx v21,r11,r0 00022fe0 li r11,0xff60 00022fe4 stvx v22,r11,r0 00022fe8 li r11,0xff70 00022fec stvx v23,r11,r0 00022ff0 li r11,0xff80 00022ff4 stvx v24,r11,r0 00022ff8 li r11,0xff90 00022ffc stvx v25,r11,r0 00023000 li r11,0xffa0 00023004 stvx v26,r11,r0 00023008 li r11,0xffb0 0002300c stvx v27,r11,r0 00023010 li r11,0xffc0 00023014 stvx v28,r11,r0 00023018 li r11,0xffd0 0002301c stvx v29,r11,r0 00023020 li r11,0xffe0 00023024 stvx v30,r11,r0 00023028 li r11,0xfff0 0002302c stvx v31,r11,r0 00023030 mfspr r11,VRsave 00023034 blr restVEC_vr10: 00023038 li r11,0xff40 0002303c lvx v20,r11,r0 00023040 li r11,0xff50 00023044 lvx v21,r11,r0 00023048 li r11,0xff60 0002304c lvx v22,r11,r0 00023050 li r11,0xff70 00023054 lvx v23,r11,r0 00023058 li r11,0xff80 0002305c lvx v24,r11,r0 00023060 li r11,0xff90 00023064 lvx v25,r11,r0 00023068 li r11,0xffa0 0002306c lvx v26,r11,r0 00023070 li r11,0xffb0 00023074 lvx v27,r11,r0 00023078 li r11,0xffc0 0002307c lvx v28,r11,r0 00023080 li r11,0xffd0 00023084 lvx v29,r11,r0 00023088 li r11,0xffe0 0002308c lvx v30,r11,r0 00023090 li r11,0xfff0 00023094 lvx v31,r11,r0 00023098 mtspr VRsave,r10 0002309c blr The only oddity I see here is with rest_VEC_vr10. All the load immediates are being done to r11, but it uses r10 for the VRSAVE. Does this look like a compiler bug and could this be the source of the stack corruption? _______________________________________________ darwin-kernel mailing list | darwin-kernel@lists.apple.com Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/darwin-kernel Do not post admin requests to the list. They will be ignored.
participants (1)
-
Mike Vannorsdel