summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorTamar Christina <tamar@zhox.com>2017-01-30 11:58:19 -0500
committerBen Gamari <ben@smart-cactus.org>2017-01-30 14:01:35 -0500
commitf41c27d3ffdddbb1afe07de1bd25205061194c93 (patch)
tree8de819f75b1fd3432bf144392ab00979ac02cbf1
parent559357384e300355b62edb3d60dcc3fadb942a50 (diff)
downloadhaskell-f41c27d3ffdddbb1afe07de1bd25205061194c93.tar.gz
Slighly clean up symbol loading error.
The symbol not found error that is triggered during lazy-loading was a bit chaotic before. This reformats it a bit to: ``` ghc-stage2.exe: | E:\...\libLLVMSupport.a: unknown symbol `_ZN4llvm5APIntC1Ejyb' ghc-stage2.exe: | E:\...\libLLVMCore.a: unknown symbol `_ZN4llvm5APInt14AssignSlowCaseERKS0_' ghc-stage2.exe: | E:\...\libLLVMCore.a: unknown symbol `_ZN4llvm13ConstantRangeC1ENS_5APIntES1_' ghc-stage2.exe: | E:\...\libLLVMCore.a: unknown symbol `_ZN4llvm14FoldingSetImplC2Ej' ghc-stage2.exe: | E:\...\libLLVMCore.a: unknown symbol `_ZN4llvm15LLVMContextImplD1Ev' ghc-stage2.exe: | E:\...\libLLVMLTO.a: unknown symbol `_ZN4llvm11LLVMContextD1Ev' ghc-stage2.exe: | E:\...\libLLVMCore.a: unknown symbol `_ZNK4llvm5Value10getContextEv' ghc-stage2.exe: ^^ Could not load 'LLVMIsMultithreaded', dependency unresolved. See top entry above. ``` I have also thought about also showing the demangled names, as it may be useful for the end user. `libgcc` seems to provide a method for this so we wouldn't need any extra dependency. Any thoughts on this or would it not be useful? Reviewers: austin, erikd, simonmar, bgamari Reviewed By: bgamari Subscribers: RyanGlScott, thomie, #ghc_windows_task_force Differential Revision: https://phabricator.haskell.org/D3027 GHC Trac Issues: #13093, #13113
-rw-r--r--rts/Linker.c7
-rw-r--r--rts/linker/PEi386.c2
2 files changed, 6 insertions, 3 deletions
diff --git a/rts/Linker.c b/rts/Linker.c
index 9462bdbbcc..8945a96d1e 100644
--- a/rts/Linker.c
+++ b/rts/Linker.c
@@ -870,12 +870,11 @@ SymbolAddr* loadSymbol(SymbolName *lbl, RtsSymbolInfo *pinfo) {
/* Symbol can be found during linking, but hasn't been relocated. Do so now.
See Note [runtime-linker-phases] */
- if (oc && oc->status == OBJECT_LOADED) {
+ if (oc && lbl && oc->status == OBJECT_LOADED) {
oc->status = OBJECT_NEEDED;
IF_DEBUG(linker, debugBelch("lookupSymbol: on-demand loading symbol '%s'\n", lbl));
int r = ocTryLoad(oc);
if (!r) {
- errorBelch("Could not on-demand load symbol '%s'\n", lbl);
return NULL;
}
@@ -893,6 +892,10 @@ SymbolAddr* lookupSymbol( SymbolName* lbl )
{
ACQUIRE_LOCK(&linker_mutex);
SymbolAddr* r = lookupSymbol_(lbl);
+ if (!r) {
+ errorBelch("^^ Could not load '%s', dependency unresolved. See top entry above.\n", lbl);
+ fflush(stderr);
+ }
RELEASE_LOCK(&linker_mutex);
return r;
}
diff --git a/rts/linker/PEi386.c b/rts/linker/PEi386.c
index 824c821c1c..f29bb8b69a 100644
--- a/rts/linker/PEi386.c
+++ b/rts/linker/PEi386.c
@@ -1326,7 +1326,7 @@ ocResolve_PEi386 ( ObjectCode* oc )
S = (size_t) lookupSymbol_( (char*)symbol );
if ((void*)S == NULL) {
- errorBelch("%" PATH_FMT ": unknown symbol `%s'\n", oc->fileName, symbol);
+ errorBelch(" | %" PATH_FMT ": unknown symbol `%s'", oc->fileName, symbol);
return false;
}
}