Re: Native build failure...

[Matt Thomas <matt%3am-software.com@localhost>]

On Jul 26, 2010, at 10:54 AM, Michael L. Hitch wrote:

> On Mon, 26 Jul 2010, Johnny Billquist wrote:
> 
>> Darn! I decided to rebuild nbgmake with debugging info, and that image 
>> didn't crash... :-( (I only added -g and rebuilt all .o files in 
>> /usr/obj/tools/gmake/build/)
>> 
>> I don't know if that piece of information is of any help...
> ...
>>>>> 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.

>  My memory is so vague on this, I don't know when this was, or it it was 
> discussed on any mailing lists.

It was quite a long time ago.