#3333: GHCi doesn't load weak symbols
--------------------------------------+-------------------------------------
Reporter: heatsink | Owner: hgolden
Type: bug | Status: assigned
Priority: normal | Milestone: 6.14.1
Component: GHCi | Version: 6.10.4
Keywords: weak, dynamic loading | Difficulty: Unknown
Os: Linux | Testcase:
Architecture: x86 | Failure: None/Unknown
--------------------------------------+-------------------------------------
Changes (by hgolden):
* owner: => hgolden
* status: new => assigned
Comment:
Replying to [comment:7 heatsink]:
> > It would be easy to add weak symbols to the symbol table, but I'm not
sure what the correct semantics should be. Perhaps weak symbols should be
subordinated to global (STB_GLOBAL) and local (STB_LOCAL) symbols. Is this
sufficient? (I haven't studied the documentation yet.)
>
> Weak symbols are never unified with local symbols. Probably it's an
error to have a weak and a local symbol with the same name in the same
file. I don't know what this means in terms of GHC's linker.
I studied the documentation after writing my previous message. Local
symbols stand alone. Global and weak symbols are in the same namespace,
but global symbols take priority.
> > Question: Is it possible to have the same weak symbol defined in more
than one module? If so, how does the linker choose?
>
> Yes. AFAICT the choice is arbitrary. GCC's linker's choice depends on
the order that files are listed on the command line. It is at least
necessary to consider SHN_UNDEF when selecting a weak symbol (defined weak
symbols take precedence over undefined weak symbols).
OK. Then I think the following approach would work:
1. Add local, global and the first occurrence of a weak symbol to the
symbol table (if the global symbol doesn't exist already). It is allowable
to have all 3 types of a single name in the symbol table.
2. When a local symbol is called for, return that. When a global symbol is
called for, return the global symbol if it exists. If a global symbol
doesn't exist, return a weak symbol if it exists.
I believe this can be implemented in the rts/Linker.c in a straightforward
way. I will start working on this. If you disagree with my analysis of the
semantics, please let me know what you want instead.
> The following statement from the ELF document appears to be relevant,
but I don't know what extracting archive members has to do with symbol
resolution.
>
> > The link editor does ''not'' extract archive members to resolve
undeļ¬ned weak symbols.
I don't think this is relevant for the GHCi linker, since it only loads
modules on demand and doesn't try to resolve undefined symbols at all.
--
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3333#comment:8>
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
