We have a byte swapping(-like problem).
Looking at the dump of the info table on PPC
(gdb) p *info
$7 = {layout = {payload = {ptrs = 0, nptrs = 4}, bitmap = 4,
large_bitmap_offset = 4, selector_offset = 4}, type = 0,
srt_bitmap = 40, code = 0x102cab2c "<`\02028c\212K%\215"}
(gdb) disassemble 0x102cab2c
Dump of assembler code for function stg_BLOCKING_QUEUE_CLEAN_info:
0x102cab2c <stg_BLOCKING_QUEUE_CLEAN_info+0>: lis r3,4146
0x102cab30 <stg_BLOCKING_QUEUE_CLEAN_info+4>: addi r3,r3,-29988
0x102cab34 <stg_BLOCKING_QUEUE_CLEAN_info+8>: bl 0x1029d0c0 <barf>
0x102cab38 <stg_BLOCKING_QUEUE_CLEAN_info+12>: .long 0x4
0x102cab3c <stg_BLOCKING_QUEUE_CLEAN_info+16>: .long 0x28
While on x86_64 we have
(gdb) p *info
$2 = {layout = {payload = {ptrs = 4, nptrs = 0}, bitmap = 4,
large_bitmap_offset = 4, __pad_large_bitmap_offset = 4,
selector_offset = 4},
type = 40, srt_bitmap = 0,
code = 0x47f950 "I\211u\020I\211}\030M\211E
M\211M(\363A\017\021MP\363A\017\021UT\363A\017\021]X\363A\017\021e\\\362A\017\021m`\362A\017\021uh\277\300%L"}
(gdb) disassemble 0x47f950
Dump of assembler code for function stg_BLOCKING_QUEUE_CLEAN_info:
0x000000000047f950 <stg_BLOCKING_QUEUE_CLEAN_info+0>: mov %rsi,0x10(%r13)
0x000000000047f954 <stg_BLOCKING_QUEUE_CLEAN_info+4>: mov %rdi,0x18(%r13)
0x000000000047f958 <stg_BLOCKING_QUEUE_CLEAN_info+8>: mov %r8,0x20(%r13)
'type' and 'srt_bitmap' are wrong on PowerPC, and swapped relative to
x86_64. The latter is correct. I believe this is CMM stuff where can I
dig further?
How did PowerPC linux ever work?
Cheers,
Gabor
On 1/16/12, Gabor Greif <[email protected]> wrote:
> It appears that I ended up with the threaded runtime. While not
> optimal for debugging, I see this:
>
> Breakpoint 1, schedule (initialCapability=0x1032b680, task=0x10336ec8)
> at rts/Schedule.c:486
> 486 r = StgRun((StgFunPtr) stg_returnToStackTop, &cap->r);
> (gdb) p cap->r
> $6 = {rR1 = {w = 0, a = 0x0, c = 0, f = 0, i = 0, p = 0x0}, rR2 = {w =
> 0, a = 0x0,
> c = 0, f = 0, i = 0, p = 0x0}, rR3 = {w = 0, a = 0x0, c = 0, f = 0, i =
> 0,
> p = 0x0}, rR4 = {w = 0, a = 0x0, c = 0, f = 0, i = 0, p = 0x0},
> rR5 = {w = 0,
> a = 0x0, c = 0, f = 0, i = 0, p = 0x0}, rR6 = {w = 0, a = 0x0, c =
> 0, f = 0,
> i = 0, p = 0x0}, rR7 = {w = 0, a = 0x0, c = 0, f = 0, i = 0, p =
> 0x0}, rR8 = {
> w = 0, a = 0x0, c = 0, f = 0, i = 0, p = 0x0}, rR9 = {w = 0, a =
> 0x0, c = 0,
> f = 0, i = 0, p = 0x0}, rR10 = {w = 0, a = 0x0, c = 0, f = 0, i =
> 0, p = 0x0},
> rF1 = 0, rF2 = 0, rF3 = 0, rF4 = 0, rD1 = 0, rD2 = 0, rL1 = 0, rSp = 0x0,
> rSpLim = 0x0, rHp = 0x0, rHpLim = 0x0, rCCCS = 0x0, rCurrentTSO =
> 0x301033c0,
> rNursery = 0x1032f178, rCurrentNursery = 0x30100040, rCurrentAlloc =
> 0x30100060,
> rHpAlloc = 0, rRet = 0}
>
>
> After loading the thread state,
>
> stg_returnToStackTop
> {
> LOAD_THREAD_STATE();
> CHECK_SENSIBLE_REGS();
> jump %ENTRY_CODE(Sp(0));
> }
>
> rightly barfs that registers are zero. Which function sets up those?
> From C or Haskell?
>
> How can I select the single-threaded runtime?
>
> Sorry for the abundance of questions...
>
> Cheers,
>
> Gabor
>
> On 1/16/12, Simon Marlow <[email protected]> wrote:
>> On 15/01/2012 00:07, Gabor Greif wrote:
>>> Hello hackers,
>>>
>>> my "hello world" program compiles and links, but when running on the
>>> embedded PowerPC board it crashes like this:
>>>
>>> (gdb) run
>>> Starting program: /root/test
>>> test: internal error: stg_ap_p_ret
>>> (GHC version 7.5.20120111 for powerpc_unknown_linux)
>>> Please report this as a GHC bug:
>>> http://www.haskell.org/ghc/reportabug
>>>
>>> Program received signal SIGABRT, Aborted.
>>> 0x0fdc0a4c in raise () from /lib/tls/libc.so.6
>>> (gdb) bt
>>> #0 0x0fdc0a4c in raise () from /lib/tls/libc.so.6
>>> #1 0x0fdc2488 in abort () from /lib/tls/libc.so.6
>>> #2 0x1029b300 in rtsFatalInternalErrorFn ()
>>> #3 0x1029b024 in barf ()
>>> #4 0x102b3f9c in stg_ap_p_info ()
>>> #5 0x1029d0ac in scheduleWaitThread ()
>>> #6 0x102c69a8 in rts_evalLazyIO ()
>>> #7 0x1029ae80 in real_main ()
>>> #8 0x1029afc8 in hs_main ()
>>> #9 0x10002168 in main ()
>>> (gdb) c
>>> Continuing.
>>>
>>> Program terminated with signal SIGABRT, Aborted.
>>> The program no longer exists.
>>
>> This back trace tells us almost nothing, I'm afraid - many different
>> kinds of corruption end up as crashes in stg_ap_p_info or some other bit
>> of the RTS.
>>
>> I suggest following the instructions in
>>
>> http://hackage.haskell.org/trac/ghc/wiki/Debugging/CompiledCode
>>
>> and see how far you get. Come back if you get stuck.
>>
>> Cheers,
>> Simon
>>
>>
>>
>>
>>>
>>>
>>> 'git grep' does not turn up any hits for 'stg_ap_p_info', and
>>> 'scheduleWaitThread' looks pretty much innocent. Where is the best
>>> place to get into debugging this?
>>>
>>> I gather stg_ap_p_info is a (global data) StgInfoTable, but then again
>>> it appears in the backtrace, (tables beside code?). Why would it barf
>>> at all?
>>>
>>> I am thinking that some host configury may still be leaking into the
>>> target, so I might be fighting a deceived RTS ('revenge tastes best
>>> when served cold'). But the host and target should be pretty
>>> comparable linux OSs.
>>>
>>> I am thankful for any hints.
>>>
>>> Cheers,
>>>
>>> Gabor
>>>
>>> _______________________________________________
>>> Cvs-ghc mailing list
>>> [email protected]
>>> http://www.haskell.org/mailman/listinfo/cvs-ghc
>>
>>
>
_______________________________________________
Cvs-ghc mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/cvs-ghc
