[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Lightning] Broken jump patching on x86_64

From: Laurent Michel
Subject: Re: [Lightning] Broken jump patching on x86_64
Date: Tue, 10 Jun 2008 13:28:56 -0400

Hi Paolo,

It's been a while, but I'm still using Lightning on MacOS for one of my projects. At this point I've ported the app to 64-bit on 10.5.3 and I'd love to get lightning up and going there too. So I grabbed the git version of lightning and tried to compile. 

I had to "mess" with the setup a little bit to get going. I couldn't figure out what to pass to configure to get a clean x86_64 target done -- the symlinks in lightning were staying on the 32b version, so I changed them manually, also MacOS expects the option -arch x86_64 to compile the files, had to manually add it to get it to compile. Finally, the test were not working at all. Turns out that on MacOS the VM areas for static vars and malloc do not have the execution bit set. So I was forced to update the test to call mmap and grab a range of addresses with suitable protection bit. This is how I modified the first lines of fib.c 

  jit_insn* codeBuffer = (jit_insn*)   mmap(0,4096*10,PROT_EXEC|PROT_READ|PROT_WRITE,MAP_ANON|MAP_PRIVATE,-1,0);
   printf("Mapping @ %p\n",codeBuffer);
  pifi      nfibs = (pifi) (jit_set_ip(codeBuffer).iptr);

For my own project, I managed the memory manually with mmap anyway, so that is not a big problem. 

After all this, I did get fib.c to compile and run on MacOS 10.5.3 in 64bit! 

Now, I have a question or two....

1) How can I _cleanly_ configure for that target ?

2) How could we change the test so that it works out-of-the-box on MacOS (in 64b, in 32b it does work fine).

3) What is the general state of the x86_64 port? What can I expect to work / not work ?  What are the big changes I should be aware of ?

Thanks a bunch!


On Jun 8, 2008, at 7:11 PM, Paolo Bonzini wrote:

   jit_insn codeBuffer[1024];
   struct jit_state _jit;
   struct foo as;

This code generates broken machine code on x86_64. It's pretty much
random what it produces. The resulting code might contain illegal
instructions or just jump wildly, causing segfaults or cause floating
point exceptions.. anyways completely undefined. What's funny is that if
CRASH is defined to 0, it does not crash. It also does not crash if
"struct foo as" is static. Can anyone confirm these issues? I don't
really know what information I can provide that might be helpful.

What happens if you:

1) add a "memset (&as, 0, sizeof (as));"

2) change _jit's definition to "(as.current)" with parentheses?



Lightning mailing list


Attachment: smime.p7s
Description: S/MIME cryptographic signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]