Yasm working with Win32

[Simon Marlow]

Peter Tanski wrote:
>> On 12/11/06, Bulat Ziganshin <bulat.ziganshin at gmail.com> wrote:
>>> Monday, December 11, 2006, 11:11:24 AM, Krasimir Angelov wrote
>>>> Is there any chance to have it working with all debug symbols?
>>>> That way it will be easier to use the Visual Debugger with GHC
>>>> compiled code.
>>>
>>> i hardly image someone who tries to debug assembler code produced
>>> by ghc :)
>
> On Dec 11, 2006, at 8:23 AM, Krasimir Angelov wrote:
>> I do :-). Some times it is the only way to find out why Visual
>> Haskell crashes Visual Studio. In this situation I am using gdb
>> because it understands the debugging information generated by gcc.
>> The debug symbols are usefull to find out which Haskell/RTS function
>> is currently executed.
>
> Bulat,
>
> I have attempted this before as well but it is very rough going and
> debugging symbols *really* help.  (Of course, this was for debugging
> RTS-code and working backwards from GHC; I know it would take a very
> long time for me to debug a pure Haskell program.)
>
> Krasimir,
>
> I am working with Peter Johnson (one of the Yasm creators) to avoid
> creating symbols.  The problem is probably the same thing the Mingw
> team ran into before.  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.  I am not sure how Mingw got around
> this--just a little research and some modifications to Yasm should do
> it.

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?

Cheers,
        Simon