[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: Native build failure...
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: Leaving directory `/usr/obj/tools/gcc/build/fixincludes'
>>> nbgmake: Entering directory `/usr/obj/tools/gcc/build/gcc'
>>>  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
> 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
> 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.
Main Index |
Thread Index |