On 13/01/2011 19:29, Edward Z. Yang wrote:
*you feel a sudden sense of deja vu*
Here is my current play on things:
- I can probably get a devel2 build with the new codegen turned on for everything. This list of errors is from that build. However, this build was originally failing, so I'm going to do a fresh devel2 build and see if I've just got some weird Franken-GHC set up.
- I can't seem to get a devel1 build with the new codegen turned on for everything built: the first invocation to the stage2 compiler segfaults.
I've been debugging 4030, since I looked at it previously to resolve the black hole problems. Doing so has given me a sense of deja vu, but I think the failure mode this time is different. The resulting executable segfaults with -O and does not segfault with -O -fno-full-laziness (strangely enough, -O0 -ffull-laziness does not segfault). The failure crops up if you do -fnew-codegen or -fno-new-codegen.
In the debugger, I've tracked the bug down to this incorrect block of assembly:
Dump of assembler code for function c2Po_info: 0x08285ac4<+0>: mov 0x48(%ebx),%eax 0x08285ac7<+3>: mov 0x4c(%ebx),%ecx 0x08285aca<+6>: mov %eax,-0x4(%ebp) 0x08285acd<+9>: mov %ecx,0x0(%ebp) 0x08285ad0<+12>: add $0x4,%ebp 0x08285ad3<+15>: add $0xfffffff8,%ebp => 0x08285ad6<+18>: jmp 0x8285ad8
which fails to initialize the top two elements of the stack after increasing the stack by a word:
(gdb) pstk 0xb7a7d4c4: 0xb7a7f01c 0xb7a7d4c0: 0x5 0xb7a7d4bc: 0x7 0xb7a7d4b8: 0x8 0xb7a7d4b4: 0x8285d58
0xb7a7d4b0: 0xb7a82db8 0xb7a7d4ac: 0x2065832e 0xb7a7d4a8: 0x2065832e 0xb7a7d4a4: 0xb7a82de4 0xb7a7d4a0: 0x45 0xb7a7d49c: 0xdeadbeef 0xb7a7d498: 0x82812e0 0xb7a7d494: 0x2065832e 0xb7a7d490: 0x2065832e 0xb7a7d48c: 0x0 0xb7a7d488: 0x7a5d52b<- bogus
Perhaps I'm misunderstanding, but the above code looks fine (if a bit stupid). It looks like this C--: x = W_[R1 + 0x48] y = W_[R1 + 0x4c] Sp[-4] = x Sp[0] = y Sp = Sp + 4 Sp = Sp - 8 So you should end up with ... Sp[4] [R1 + 0x4c] Sp[0] [R1 + 0x48] perhaps check what R1 points to?
But I don't know where c2Po_info is coming from; it's not in the C-- dump of the program itself, so I assume it's in some library (but then why is it affected by optimizations?). Can I easily get C-- dumps of all the librarise?
It must be in a library - this is why -fno-new-codegen doesn't affect it, because the library is already compiled. You can grep for the symbol in the library .o files, and then compile the offending module with -ddump-cmm (the symbol name might change, so you might have to recompile and debug the program again to get the new symbol name). Cheers, Simon
I suspect that I should actually do the full (and not just fast) test suite on the stage2-new-codegen build to squirrel out more of these optimization bugs, since debugging a buggy stage2 compiler produced by a buggy stage1 compiler... does not seem like fun at all.
I might suspend this work until I'm back in town and we can have a chat in person. I guess I should put my repository somewhere :-)
Cheers, Edward
_______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users