On Mon, 26 Jul 2010, Matt Thomas wrote:
If I read things right, it's one of these two lines wich cause the segfault though: ce1: c8 50 ad d8 bisl2 r0,0xffffffd8(fp) ce5: e8 a6 0d 05 blbs 0xd(r6),cee <update_file+0x428>...blbs uses a longword access so if r6+0xd is at 0xffd..0xfff and the page following isn't mapped you will get a segfault.Yes, but my first guess is that it would be the bisl2 instruction. The address (if my conversions are right) would point to pc pointing at the blbs after the trap, and I assume the pc have been updated at that point? But I might be totally messing up my address calculations as well...I think Matt want's the VA that caused the fault, which would likely be the contents of R6 + 0xd. I have a rather vague memory of something similar where the target address of the blbs was indexed with a non-multiple-of-four offset which caused a memory fault. The same rather vague memory seems to recall that Matt came up with a code generation change that did the blbs differently if the indexed offset was not a multiple of 4. A -g build could hide the problem by re-arranging the code such that the test is done differently, or the data re-arranged so that the 4 bytes at (r6) are valid.But that was for extzv and inszv but not blb[sc]. Basically for unaligned displacements, use bb[sc] instead. Shouldn't be that hard to code up.
The memory may be vague, but searching my mail finds what I remember, and it was blbs:
http://mail-index.NetBSD.org/port-vax/2009/05/28/msg000691.html I don't know if there was any followup to that message though. -- Michael L. Hitch mhitch%montana.edu@localhost Computer Consultant Information Technology Center Montana State University Bozeman, MT USA