Peter Tanski wrote:
> 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.
You haven't allayed my fears. If a Yasm-generated object file has a special
.reloc/.stab section to handle complex relocations, and the GNU linker
understands this special section, won't the MS linker choke on it? Or are
complex relocations done in the same way by the MS tools too?
Cheers,
Simon
_______________________________________________
Cvs-ghc mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/cvs-ghc
