stg_upd_frame_info still broken

Simon Peyton Jones simonpj at microsoft.com
Tue Oct 27 14:57:51 UTC 2015


 I'm pretty sure this error is being produced by ghc's own runtime linker, which has a built-in symbol table (essentially just a C array of structs of { "foo", &foo }). This array is built from a bunch of macros such as SymI_HasProto(stg_upd_frame_info), which used to be present in rts/Linker.c but were moved to rts/RtsSymbols.c in commit abc214b77d. I guess that commit or a related one was not correct. Windows is the only (major?) platform on which the ghc executable is built statically by default, and therefore uses ghc's own runtime linker.

Ah. That sounds very plausible Thanks

S

From: Reid Barton [mailto:rwbarton at gmail.com]
Sent: 27 October 2015 14:57
To: Ben Gamari
Cc: Simon Peyton Jones; ghc-devs at haskell.org
Subject: Re: stg_upd_frame_info still broken

On Tue, Oct 27, 2015 at 10:46 AM, Ben Gamari <ben at well-typed.com<mailto:ben at well-typed.com>> wrote:
Simon Peyton Jones <simonpj at microsoft.com<mailto:simonpj at microsoft.com>> writes:
> I cloned an entirely new GHC repository.
> Then 'sh validate'.
> Same result as before: any attempt to run GHCi fails with an unresolved symbol.
>
> bash$ c:/code/HEAD-1/inplace/bin/ghc-stage2 --interactive
>
> GHCi, version 7.11.20151026: http://www.haskell.org/ghc/<https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fwww.haskell.org%2fghc%2f&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7ce0433e9616f94207642908d2deded4ff%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=RYlwVuvgZKZDInxJ2iDfFNuxK0UX2FGcSeplXjv4Yg0%3d>  :? for help
>
> ghc-stage2.exe: unable to load package `ghc-prim-0.4.0.0'
>
> ghc-stage2.exe: C:\code\HEAD-1\libraries\ghc-prim\dist-install\build\HSghc-prim-0.4.0.0.o: unknown symbol `_stg_upd_frame_info'
>
> How could I actually find what the problem is? Trying random things
> and hoping the problem goes away clearly is not working.
>
I would first try to find the object file which is supposed to provide
this symbol and figure out whether the problem is one of the RTL
(which is what I would put my money on) or some part of the build
toolchain.

 I'm pretty sure this error is being produced by ghc's own runtime linker, which has a built-in symbol table (essentially just a C array of structs of { "foo", &foo }). This array is built from a bunch of macros such as SymI_HasProto(stg_upd_frame_info), which used to be present in rts/Linker.c but were moved to rts/RtsSymbols.c in commit abc214b77d. I guess that commit or a related one was not correct. Windows is the only (major?) platform on which the ghc executable is built statically by default, and therefore uses ghc's own runtime linker.
I'll try building a Linux ghc with GHC_DYNAMIC=NO and if it exhibits the same problem I should be able to provide a quick fix.
Regards,
Reid Barton
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20151027/487b1e12/attachment-0001.html>


More information about the ghc-devs mailing list