Windows-native GHC (Yasm issue)

Peter Tanski p.tanski at gmail.com
Wed Nov 22 10:22:08 EST 2006


On Nov 22, 2006, at 4:18 AM, Simon Marlow wrote:

> Peter Tanski wrote:
>> On Nov 21, 2006, at 11:48 AM, Simon Marlow wrote:
>>> Peter Tanski wrote:
>>>
>>>> I tested out the 0.5.0 build of yasm on assembler output from GHC
>>>> 6.6  and yasm chokes on expressions like this:
>>>>   _Main_main_srt - (_Main_main_info) + 0
>>>> It gives the error "expression too complex," which I tracked to a
>>>> function in the yasm source file libyasm/value.c.  I am still
>>>> looking  into it.
>>>
>>>
>>> It's possible YASM doesn't grok these.  I doubt that gcc ever   
>>> generates them, which is probably why.
>>>
>>> This is an example of a complex relocation.  If the two symbols  
>>> are  defined in the current file and are in the same section,  
>>> then the  offset can be computed statically by the assembler.   
>>> Otherwise it  has to be left as a relocation in the object file  
>>> for the linker;  in which case *one* of the symbols must be in  
>>> the same section as  the relocation, and the assembler emits a PC- 
>>> relative relocation  descriptor (eg. R_X86_PC32 is a 32-bit PC- 
>>> relative relocation in  ELF).  A PC-relative relocation is of the  
>>> form (current address +  offset + symbol).
>>>
>>> It turns out that GNU binutils can't handle the 64-bit PC- 
>>> relative  relocation yet, which is why we use 32-bit relative  
>>> offsets in our  info tables on x86_64 (there's a small comment  
>>> about this in  PprMach:754).
>>
>> ... I'm  not sure where to go from here: there are two solutions.   
>> I could  modify the NCG to output the correct data sections and  
>> hope Yasm  picks up the reference or I could look into fixing Yasm.
>
> By "modify the NCG to output the correct data sections" do you mean  
> putting the two symbols in the same section for a relative  
> reference?  This means putting SRTs in the text section.  We used  
> to do this (this was one workaround for the lack of 64-bit relative  
> relocations on x86_64), but it's not really the right thing; SRTs  
> should go in the read-only data section to avoid polluting the code  
> cache.

I meant sorting out the potential relocation symbols ourselves and  
put them into a '.reloc' section ('.reloc' is for COFF).  This is  
something the assembler (Yasm) should do.

Cheers,
Pete


More information about the Cvs-ghc mailing list