Yasm working with Win32
simonmar at microsoft.com
Mon Dec 11 09:34:32 EST 2006
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.
> 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.)
> 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
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?
More information about the Cvs-ghc