Windows-native GHC (Yasm issue)
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
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.
More information about the Cvs-ghc