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
_______________________________________________
Cvs-ghc mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/cvs-ghc
