#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
