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).
That seems right on the money. Thank you for the explanation. 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. I would opt for the latter
as that is the correct solution (the assembler should generate the
relocation entries). I shall ask the yasm people-- hopefully this is
the only issue.
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.
Cheers,
Simon
_______________________________________________
Cvs-ghc mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/cvs-ghc
