#5748: ghci segfault on OS X after dlsym failed lookup
---------------------------------+------------------------------------------
Reporter: gwright | Owner: gwright
Type: bug | Status: new
Priority: normal | Milestone:
Component: GHCi | Version: 7.2.1
Keywords: | Os: MacOS X
Architecture: Unknown/Multiple | Failure: GHCi crash
Difficulty: Unknown | Testcase:
Blockedby: | Blocking:
Related: |
---------------------------------+------------------------------------------
Comment(by gwright):
The failure to lookup the "approx_tab" symbol is a real, and long-
standing, linker bug.
First, my little experiment to not strip of the first character of a
symbol if it wasn't "_" did not work. Checking the source of {{{dlsym}}}
showed why: {{{dlsym}}} always prefixes its symbol argument with an
underscore before it searches the symbol tables. It can never find a
symbol that does not start with a leading underscore.
The bug is that {{{dlsym}}} is ever being asked to resolve "approx_tab" at
all. The Apple documentation is a bit confusing on this point, but here's
my understanding of it:
The documentation uses "external" in two different senses: 1) "external"
relocations, indicated by {{{reloc->r_extern == 1}}} mean that a symbol
must be looked up in the symbol table at offset {{{reloc->r_symbolnum}}}.
(Non-external relocations simply involve computing offsets within the
current section of the object module.) 2) "External" symbols, indicated
by the {{{N_EXT}}} flag in the symbol table entry (an {{{nlist_64}}}
struct). This sense of "external" means that the symbol is either a)
defined within the current object module and available for import by other
object modules, or b) that the symbol is undefined in the current object
module and must be found elsewhere.
The symbol "approx_tab" is external but not External. It should be looked
up in the symbol table ("external" in the first sense) but not resolved by
{{{lookupSymbol}}}, since it is not "External" in the second sense.
Instead, the symbol table entry contains the section number
({{{nlist->n_sect}}}) and offset within the section ({{{nlist->n_value}}})
of the symbol.
This is straightforward to fix, though it's puzzling why it ever worked.
The code in {{{rts/Linker.c}}} assumes that relocations of type
{{{X86_64_RELOC_GOT}}} and {{{X86_64_RELOC_GOT_LOAD}}} are always
"External" in the second sense, which is wrong. It's also strange that a
symbol reference internal to an object module goes through the global
offset offset table (at least I think it's strange, maybe there is a good
but not obvious reason for it.)
I'll get this fixed up and tested today.
--
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/5748#comment:6>
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
