Re: Native build failure...

["Michael L. Hitch" <mhitch%lightning.msu.montana.edu@localhost>]

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.

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

--
Michael L. Hitch                        mhitch%montana.edu@localhost
Computer Consultant
Information Technology Center
Montana State University        Bozeman, MT     USA