Port-vax archive

[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
Computer Consultant
Information Technology Center
Montana State University        Bozeman, MT     USA

Home | Main Index | Thread Index | Old Index