On Dec 11, 2006, at 9:34 AM, Simon Marlow wrote:
Peter Tanski wrote:
Windows loader cannot handle .stab and .stabstr sections. When
Yasm handles complex relocations it does what GAS does (or did, as
far as I know): it puts the symbols to be relocated into a .reloc
section and writes the symbols explicitly into a symbol table.
When Mingw's 'ld' gets to the relocations it calculates the
addresses for the image file and also puts the symbols in .stab
and .stabstr sections.
Interesting - so do you think MS linker can't handle these complex
relocations? If that's the case, it will cause us difficulties for
doing the native Windows back end, right?
After a bit of digging I think my impression from the mingw problem
(.stab and .stabstr sections) was wrong: this is a different
problem. After comparing the objdump of a yasm-compiled bad
executable (not stripped) and the normal -fasm (gas-compiled)
executable the yasm-compiled object file (and executable) contain a
spurious .comment section. This seems to be a simple bug in yasm, so
once it is fixed the native Windows backend shouldn't have any trouble.
On a somewhat related note, there would be a problem if all symbols
were stripped from object files prior to passing them to 'ld' or MS's
'link': the .stab and .stabstr sections are required for the linker
to relocate the symbols; otherwise they are unnecessary in an
executable ("image") file.
The good news is the problem is apparently easy to fix and the result
should be compatible with MS tools.
Cheers,
Pete
_______________________________________________
Cvs-ghc mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/cvs-ghc
