#5004: loading stripped libHsghc-7.0.2.a fails ---------------------------------+------------------------------------------ Reporter: pbrisbin | Owner: duncan Type: bug | Status: new Priority: highest | Milestone: 7.2.1 Component: Compiler | Version: 7.0.2 Keywords: | Testcase: Blockedby: | Difficulty: Os: Linux | Blocking: Architecture: Unknown/Multiple | Failure: GHCi crash ---------------------------------+------------------------------------------
Comment(by duncan): Replying to [comment:17 twhitehead]: > Just finished running into this on Debian. Looks like the problem is that the ''keepCAFsForGHCi.o'' object file in the archive has no symbols but debug ones. Thanks, this turns out to be the core issue. It's fortunately nothing to do with debug symbols or jump islands. So when linking we definitely need a symbol table and its corresponding string table. Using `strip` on a `.o` or `.a` file will remove both tables. In this situation neither the system linker nor the GHCi linker cannot do anything with it. Linux distros of course do not use just `strip`, they typically use `strip --strip-unneeded`. The `strip --strip-unneeded` command does not remove symbol tables, it just filters out the symbols not needed for relocation processing. There is one important exception to the above however: `strip --strip- unneeded` '''does''' remove the symbol table when the symbol table is empty (after the usual filtering). That is exactly what is happening with `keepCAFsForGHCi.o`. The `keepCAFsForGHCi.c` has just one function, and it is conditionally compiled so that it only appears only in the dynamic way. So `keepCAFsForGHCi.dyn_o` has the function in it, while the ordinary `keepCAFsForGHCi.o` is basically an empty object file. So when we `strip --strip-unneeded` on the `libHSghc.a` then the archive member `keepCAFsForGHCi.o` ends up with no symbol table. So, the solution is probably to recognise when an object file exports no symbols and has no relocations requiring symbols. Thus for these object files we do not need their symbol table at all. So it should be just a matter of adjusting the order in which various things are validated and checked. It is interesting to note that the system linker does not complain about object files with no symbol table, it just fails when it cannot find the target symbols that it needs. So it apparently just treats lack of a symbol table as no symbols. Perhaps we can do the same. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/5004#comment:19> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler _______________________________________________ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs