#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):
So I have a fix! I've pushed the patch for ghc-head one for the 7.0.x
branch is attached.
{{{
Thu May 12 17:43:59 BST 2011 Duncan Coutts <[email protected]>
* Make the GHCi linker handle partially stripped object files (#5004)
When you use 'strip --strip-unneeded' on a ELF format .o or .a file, if
the object file has no global/exported symbols then 'strip' ends up
removing the symbol table entirely. Previously the GHCi linker assumed
there would always be exactly one symbol table and exactly one string
table. In fact, in ELF object files there is no such limitation, instead
each section points to the other sections it needs, in particular
relocation sections have a link to the symbol table section they use and
symbol table sections have a link to the corresponding string table.
So instead of assuming there will always be a global symbol and string
table, all we have to do is validate and follow these links. Then, when
we encounter an empty object file that has no symbols then we handle it
correctly, because since it's empty we never process any relocations and
so never have to follow any links to non-existant symbol tables.
Also, in the case where an object is fully stripped, we can now detect
this more reliably and emit a more helpful error message, e.g:
libHSghc-7.1.20110509.a(DsMeta.o): relocation section #2 has no symbol
table
This object file has probably been fully striped. Such files cannot be
linked.
}}}
--
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/5004#comment:20>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
_______________________________________________
Glasgow-haskell-bugs mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
