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, 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

Home | Main Index | Thread Index | Old Index