[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: Native build failure...
Matt Thomas wrote:
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
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.
(gdb) core nbgmake.core
Core was generated by `nbgmake'.
Program terminated with signal 11, Segmentation fault.
#0 0x00020b91 in ?? (2135209632, 18)
I assume you mean machdep.printfataltraps ? I can't change it with
sysctl... Not even with an insecure kernel. How do I change it? (Can't
find anything obvious in the config files either.)
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...
Main Index |
Thread Index |