Re: Bootstrapping ghc through cross-build?

[Samuel Thibault <sthibault@debian.org>]

Hello,

Samuel Thibault, le sam. 07 sept. 2024 23:02:06 +0200, a ecrit:
> I eventually reserved an arm64 node to get more memory addressing space,
> and that did work. I had to tinker a couple things (will report them),
> and eventually got a ghc_hurd-amd64.deb. Now building it natively.

I had gotten out of time with the issues at hand, I'm giving it a try
again now. I'm getting a segfault very early. When proceeding step by
step, I end up in stg_ap_p_fast, at:

   0x00000000081c2db1 <+153>:     inc    %rax
   0x00000000081c2db4 <+156>:     cmp    $0x1,%rax
   0x00000000081c2db8 <+160>:     jb     0x81c2da3 <stg_ap_p_fast+139>
   0x00000000081c2dba <+162>:     mov    %rcx,%rbx
   0x00000000081c2dbd <+165>:     add    $0x10,%rbp
=> 0x00000000081c2dc1 <+169>:     jmp    *0x0(%rbp)
   0x00000000081c2dc4 <+172>:     add    $0xfffffffffffffff8,%rbp
   0x00000000081c2dc8 <+176>:     lea    -0x2ef7(%rip),%rax        # 0x81bfed8 <stg_ap_

which jumps to 0x0000000009804098, which doesn't make sense since it's
on the heap, without X permission. That location happens to contain
0x00000000081be850, which happens to be exactly stg_ap_2_upd_info, which
thus makes sense.

So it seems that somehow the stg_ap_p_fast code doesn't know it is
supposed to do another dereference to reach the proper code. I however
didn't find the source code for stg_ap_p_fast, I guess it's generated
since it's about different ways to call a continuation, is that
rts/Apply.cmm perhaps? I'm wondering if there are some configuration
bits that I am missing to set somewhere to properly fix the jumping
convention?

Samuel