Yasm working with Win32
p.tanski at gmail.com
Tue Dec 12 00:14:42 EST 2006
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.
More information about the Cvs-ghc