[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: Native build failure...
On Mon, 26 Jul 2010, Matt Thomas wrote:
If I read things right, it's one of these two lines wich cause the segfault
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:
I don't know if there was any followup to that message though.
Michael L. Hitch mhitch%montana.edu@localhost
Information Technology Center
Montana State University Bozeman, MT USA
Main Index |
Thread Index |