search for: x86compilationcallback_sse

I don't know how to file a PR, but I have a patch (see below), that should work regardless of abi differences, since it relies on the compiler to do the though job. void X86CompilationCallback_SSE(void) { char * SAVEBUF= (char*) alloca(64+12); // alloca is 16byte aligned asm volatile ( "movl %%eax,(%0)\n" "movl %%edx,4(%0)\n" // Save EAX/EDX/ECX "movl %%ecx,8(%0)\n" :: "r"(SAVEBUF+64): "memory" ); asm vo...

Hello. I found that the X86CompilationCallback_SSE wrapper for X86CompilationCallback2 is not setting up properly for the PIC invocation. Before you can correctly invoke a function via the Procedure Linkage Table (plt), the ABI mandates that ebx is pointing to the GOT (Global Offset Table) (see http://www.greyhat.ch/lab/downloads/pic.html) Dump of...

Hello, Corrado > Before you can correctly invoke a function via the Procedure Linkage > Table (plt), the ABI mandates that ebx is pointing to the GOT (Global > Offset Table) (see http://www.greyhat.ch/lab/downloads/pic.html) This is known issue, just nobody realized, that we have bunch of non- PIC-aware assembler code. :) Fixing would be not so trivial though, mostly due to ABI

On Mar 11, 2009, at 2:39 PM, Corrado Zoccolo wrote: > I don't know how to file a PR, but I have a patch (see below), that > should work regardless of abi differences, since it relies on the > compiler to do the though job. > > void X86CompilationCallback_SSE(void) { > char * SAVEBUF= (char*) alloca(64+12); // alloca is 16byte aligned How do you ensure it's 16-byte aligned? Can you declare a local array and specify alignment using attribute __aligned? Evan > > asm volatile ( > "movl %%eax,(%0)\n" > "mov...

...hat it can't clobber those registers. Dan On Mar 11, 2009, at 2:39 PM, Corrado Zoccolo wrote: > I don't know how to file a PR, but I have a patch (see below), that > should work regardless of abi differences, since it relies on the > compiler to do the though job. > > void X86CompilationCallback_SSE(void) { > char * SAVEBUF= (char*) alloca(64+12); // alloca is 16byte aligned > > asm volatile ( > "movl %%eax,(%0)\n" > "movl %%edx,4(%0)\n" // Save EAX/EDX/ECX > "movl %%ecx,8(%0)\n" > :: "r"(SAVEBUF+64): &quot...

On Thu, Mar 12, 2009 at 5:18 PM, Dan Gohman <gohman at apple.com> wrote: > This looks like an interesting idea. As written, the inline asms > aren't safe > though; they reference %eax, %edx, etc. without declaring such things in > constraints, so the compiler wouldn't know that it can't clobber those > registers. > > Dan > I don't know how to specify

I've created a patch (attached to the bug): http://llvm.org/bugs/attachment.cgi?id=2744, that goes in a different direction, and solves the safety problems. The patch uses original asm, but removes the call through plt, and puts the invoked function in an anonymous namespace. This allows the static linker to always know the location of the jump, removing the need for PIC invocation setup. This

It looks fine to me. Anton, does it look ok to you? Evan On Mar 20, 2009, at 2:33 PM, Corrado Zoccolo wrote: > I've created a patch (attached to the bug): > http://llvm.org/bugs/attachment.cgi?id=2744, that goes in a different > direction, and solves the safety problems. > The patch uses original asm, but removes the call through plt, and > puts the invoked function in an

Hi Evan > It looks fine to me. Anton, does it look ok to you? This looks ok for me modulo win64+vcpp issues, which I mentioned in the PR (external .asm files). The anonymous namespace thing should be guarded by define (either _M_AMD64 or X86_64_JIT && _MSC_VER, I'd prefer the latter). -- With best regards, Anton Korobeynikov. Faculty of Mathematics & Mechanics, Saint

Hello, Nathan > or if it should be a configure test, which might be safer. Are there > any x86 platforms (other than apple) that don't need PLT-indirect calls? Yes, mingw. However just tweaking the define is not enough - we're not loading address of GOT into ebx before the call (on 32 bit ABIs) thus the call will be to nowhere. -- With best regards, Anton Korobeynikov Faculty of

...opl %ebp\n" + CFI(".cfi_adjust_cfa_offset -4\n") + CFI(".cfi_restore %ebp\n") + "ret\n" + CFI(".cfi_endproc\n") + SIZE(X86CompilationCallback) + ); + + // Same as X86CompilationCallback but also saves XMM argument registers. + void X86CompilationCallback_SSE(void); + asm( + ".text\n" + ".align 8\n" + ".globl " ASMPREFIX "X86CompilationCallback_SSE\n" + ".local .local_got_stub_SSE\n" + TYPE_FUNCTION(X86CompilationCallback_SSE) + ASMPREFIX "X86CompilationCallback_SSE:\n" + CF...

...loc. Without the call instruction there, it works just fine. If we store the value 10 into tmp2.i.i, 10 gets reloaded after the call. However, the call instruction somehow overwrites the data stored in tmp2.loc which surprises me. Using the debugger, we watched that memory location and saw that X86CompilationCallback_SSE was modifying it for some reason. After lookin at X86CompilationCallback_SSE, we don't see how it is touching that memory location. A few other things. If i move the alloca of tmp2.loc into the codeRepl block, the error does not occur. If i add a print directly after the current alloca of...

Hi all, I've encountered a couple of minor build issues on Solaris that have crept in since 2.5, fixes below: 1. In lib/Target/X86/X86JITInfo.cpp, there is: // Check if building with -fPIC #if defined(__PIC__) && __PIC__ && defined(__linux__) #define ASMCALLSUFFIX "@PLT" #else #define ASMCALLSUFFIX #endif Which causes a link failure due to the non-PLT

...:getName (this=0x9344910) at /cvs/llvm/include/llvm/Value.h:110 #8 0xb6f241c7 in (anonymous namespace)::JITResolver::JITCompilerFn (Stub=0xb5667620) at JITEmitter.cpp:267 #9 0xb6de70e4 in X86CompilationCallback2 (StackPtr=0xbf856f60, RetAddr=-1251576288) at X86JITInfo.cpp:350 #10 0xb6de6d31 in X86CompilationCallback_SSE () from phpllvm.so #11 0xb5667624 in ?? () #12 0x0a295548 in ?? () #13 0x00000001 in ?? () #14 0x0a2920d0 in ?? () #15 0x00000000 in ?? () (gdb) up 8 #8 0xb6f241c7 in (anonymous namespace)::JITResolver::JITCompilerFn (Stub=0xb5667620) at JITEmitter.cpp:267 267 << I->first &l...