Re: Native build failure...

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

On Jul 24, 2010, at 1:57 PM, Johnny Billquist wrote:

> Matt Thomas wrote:
>> On Jul 15, 2010, at 11:25 AM, Johnny Billquist wrote:
>>> Anyone having any idea?
>>> 
>>> This already when building tools...
>>> 
>>> ======
>>> .
>>> .
>>> .
>>> nbgmake[1]: Leaving directory `/usr/obj/tools/gcc/build/fixincludes'
>>> nbgmake[1]: Entering directory `/usr/obj/tools/gcc/build/gcc'
>>> [1]   Segmentation fault (core dumped) (cd ./gcc && /us...
>>> nbgmake: *** [install-gcc] Error 139
>> seem to remember you need to up the default stack size
> 
> It does not seem to be a problem with the stack size.
> I've tried looking a bit more at it, although not entirely successful, since 
> the build procedure is so convoluted and complex that it's hard for me to 
> follow.
> 
> But anyway, what I have found out so far is that:
> o it's nbgmake that craches with a segfault, not gcc.
> o it crashes when doing the install of gcc. It has already successfully built 
> the whole thing.
> o I've tried with small and big stacksizes, without it making a difference.
> o the routine in nbgmake it seems to crash in is update_file
> 
> I've tried looking through that routine, but the assembler output I see in 
> objdump is just cryptic. Probably atleast partly because it's been through 
> the optimizer.
> 
> 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>
> 
> not that I can understand why...

What does GDB say?  is hw.printfataltraps on?  I can venture a guess but I'd 
like to know the VA of the fault.

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.