More on KEXTs & Altivec stack corruption
More on KEXTs & Altivec stack corruption
- Subject: More on KEXTs & Altivec stack corruption
- From: "Mike Vannorsdel" <email@hidden>
- Date: Fri, 11 Oct 2002 21:56:33 -0600
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 | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/darwin-kernel
Do not post admin requests to the list. They will be ignored.