search for: retaddr

...); asm volatile ( // Save all XMM arg registers "movaps %%xmm0, (%0)\n" "movaps %%xmm1, 16(%0)\n" "movaps %%xmm2, 32(%0)\n" "movaps %%xmm3, 48(%0)\n" :: "r"(SAVEBUF) : "memory" ); intptr_t *StackPtr=0, RetAddr=0; asm volatile ( // get stack ptr and retaddr "movl %%ebp,%0\n" "movl 4(%%ebp),%1\n" :"=r"(StackPtr), "=r"(RetAddr) :: "memory" ); X86CompilationCallback2(StackPtr,RetAddr); // gcc knows how to call this according to the A...

...e callee when we jump to it. It is here when we run into a problem in LLVM. Consider the following CPS call to @bar and how it will return: ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; define void @foo (i8** %sp, ...) { someBlk: ; ... ; finish stack frame by writing return address %retAddr = blockaddress(@foo, %retpt) store i8* %retAddr, i8** %sp ; jump to @bar tail call void @bar(i8** %sp, ...) retpt: ; <- how can @bar "call" %retpt? %sp2 = ??? %val = ??? ; ... } define void @bar (i8** %sp, ...) { ; perform a return %retAddr0 = load i8*,...

...-08-19 11:39:14.769549714 +0000 @@ -396,6 +396,7 @@ // PC-relative branch instead of loading the actual address. (This is // considerably shorter than the 64-bit immediate load already there.) // We assume here intptr_t is 64 bits. +#if defined (__LP64__) intptr_t diff = NewVal-RetAddr+7; if (diff >= -2147483648LL && diff <= 2147483647LL) { *(unsigned char*)(RetAddr-0xc) = 0xE9; @@ -405,6 +406,11 @@ ((unsigned char*)RetAddr)[0] = (2 | (4 << 3) | (3 << 6)); } sys::ValgrindDiscardTranslations((void*)(RetAddr-0xc), 0xd); +#else...

...a problem in LLVM. >> Consider the following CPS call to @bar and how it will return: >> ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; >> define void @foo (i8** %sp, ...) { >> someBlk: >> ; ... >> ; finish stack frame by writing return address >> %retAddr = blockaddress(@foo, %retpt) >> store i8* %retAddr, i8** %sp >> ; jump to @bar >> tail call void @bar(i8** %sp, ...) >> retpt: ; <- how can @bar "call" %retpt? >> %sp2 = ??? >> %val = ??? >> ; ... >> } >> define void...

Hi, I'm working on bringing up complete coverage for a Gentoo x32 "desktop" system. I've been cooking up quite a few patches for various packages to push upstream, but right now, the biggest blocker is the lack of support for building with/codegen targeting x32 in llvm/clang. Since the x32 patches were sent last year, I see support code has landed in LLVM, and basic handling of

...-08-19 11:39:14.769549714 +0000 @@ -396,6 +396,7 @@ // PC-relative branch instead of loading the actual address. (This is // considerably shorter than the 64-bit immediate load already there.) // We assume here intptr_t is 64 bits. +#if defined (__LP64__) intptr_t diff = NewVal-RetAddr+7; if (diff >= -2147483648LL && diff <= 2147483647LL) { *(unsigned char*)(RetAddr-0xc) = 0xE9; @@ -405,6 +406,11 @@ ((unsigned char*)RetAddr)[0] = (2 | (4 << 3) | (3 << 6)); } sys::ValgrindDiscardTranslations((void*)(RetAddr-0xc), 0xd); +#else...

...> Consider the following CPS call to @bar and how it will return: >> >> ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; >> >> define void @foo (i8** %sp, ...) { >> someBlk: >> ; ... >> ; finish stack frame by writing return address >> %retAddr = blockaddress(@foo, %retpt) >> store i8* %retAddr, i8** %sp >> ; jump to @bar >> tail call void @bar(i8** %sp, ...) >> >> retpt: ; <- how can @bar "call" %retpt? >> %sp2 = ??? >> %val = ??? >> ; ... >> >&...

Paolo Invernizzi wrote: > There was a similar problem some time ago, and was resolved with alloca. > I think it's a better solution to use the stack instead of the heap... I tend to agree, but the constructors won't get called if it's an object array -- anyway, this particular case there was no objects, just pointers and bools so alloca should be fine. I'll leave it to

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

.../ Save all XMM arg registers > "movaps %%xmm0, (%0)\n" > "movaps %%xmm1, 16(%0)\n" > "movaps %%xmm2, 32(%0)\n" > "movaps %%xmm3, 48(%0)\n" > :: "r"(SAVEBUF) : "memory" ); > > intptr_t *StackPtr=0, RetAddr=0; > > asm volatile ( // get stack ptr and retaddr > "movl %%ebp,%0\n" > "movl 4(%%ebp),%1\n" > :"=r"(StackPtr), "=r"(RetAddr) :: "memory" ); > > X86CompilationCallback2(StackPtr,RetAddr); // gcc knows how to...

.../ Save all XMM arg registers > "movaps %%xmm0, (%0)\n" > "movaps %%xmm1, 16(%0)\n" > "movaps %%xmm2, 32(%0)\n" > "movaps %%xmm3, 48(%0)\n" > :: "r"(SAVEBUF) : "memory" ); > > intptr_t *StackPtr=0, RetAddr=0; > > asm volatile ( // get stack ptr and retaddr > "movl %%ebp,%0\n" > "movl 4(%%ebp),%1\n" > :"=r"(StackPtr), "=r"(RetAddr) :: "memory" ); > > X86CompilationCallback2(StackPtr,RetAddr); // gcc knows how to...

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 assembler code for function

...function in epilogue, similar to EH_RETURN) There is a new calling convention: CC_X86_32_TailCall which is ~ CC_X86_32_C minus ECX. There are some modifications in X86InstrInfo.td There are new X86 DAG nodes: TRUETAILCALL TC_RETURN There is some voodoo in X86RegisterInfo.cpp to deal with the RETADDR problem described in X86ISelLowering.cpp comments. (callee has more args than caller -> there needs to be space between RETADDR stack slot and ebp/spilled registers for safely moving the RETADDR to) any comments, critique, suggestions welcome. regards arnold -------------- next part ----------...

...> Consider the following CPS call to @bar and how it will return: >> >> ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; >> >> define void @foo (i8** %sp, ...) { >> someBlk: >> ; ... >> ; finish stack frame by writing return address >> %retAddr = blockaddress(@foo, %retpt) >> store i8* %retAddr, i8** %sp >> ; jump to @bar >> tail call void @bar(i8** %sp, ...) >> >> retpt: ; <- how can @bar "call" %retpt? >> %sp2 = ??? >> %val = ??? >> ; ... >> >&...

...ss, split the basic block *after* the call instruction, then generate a BlockAddress as follows: if (auto CL = dyn_cast<CallInst>(&*I)) { BasicBlock *callblock = (*CL)->getParent(); BasicBlock *postblock = callblock->splitBasicBlock((*CL)->getNextNode()); BlockAddress *retaddr = BlockAddress::get(postblock); ... } This works well except that the BlockAddress is slightly off. I run into the problem that during code generation, my BlockAddress is moved past the instructions that store arguments. E.g., if the function returns an argument, %rax is first spilled somewhere...

...calling convention: > CC_X86_32_TailCall > which is ~ CC_X86_32_C minus ECX. > > There are some modifications in > X86InstrInfo.td > > There are new X86 DAG nodes: > TRUETAILCALL > TC_RETURN > > > There is some voodoo in X86RegisterInfo.cpp to deal with the > RETADDR problem described in X86ISelLowering.cpp comments. > (callee has more args than caller -> there needs to be space > between RETADDR stack slot and ebp/spilled registers for safely > moving the RETADDR to) > > any comments, critique, suggestions welcome. > regards arnold > &g...

...y - which essentially means an API that can reliably iterate through all of the stack frames, starting from the current function, and calculate the correct return address for each stack frame. I'm envisioning something like this: frame = llvm.currentframe(); while frame != NULL { retaddr = llvm.returnaddr(frame); // do stack tracing using frame and retaddr to identify stack roots. frame = llvm.nextframe(frame); } This is essentially what I do now with the EBP register - but it would be better if it were encapsulated behind an API, so that frontends wouldn't hav...

On Apr 10, 2011, at 2:45 PM, Talin wrote: > I wonder - would something like this allow for multiple stacks for a single thread? I'm thinking of something like continuations / fibers / green threads, which would be very handy. I haven't looked at the proposal, but yes, this would be very useful functionality for LLVM to provide. -Chris > > On Wed, Mar 23, 2011 at 3:07 AM,

...t seems to take two seeks before it falls over) and for some vorbis file after playback as finished. Here's a stack crawl for the seek. loading symbols segment violation occurred _f0_fit_clear: _f0_fit_clear: +002a ea3039c6: * 103b cmpl (%eax), %edx Fader:sc frame retaddr fd042014 ea303e52 free_look + 0000005a fd04202c ea30627b free_look + 0000009f fd042048 ea2f3196 vorbis_dsp_clear + 0000033e fd042074 ea2eed99 _decode_clear + 0000002d fd042084 ea2efc8f ov_raw_seek + 0000007f fd04209c ea2eff6d ov_pcm_seek + 00000221 fd042100 ea2f022e ov_time_see...

...uot;C" { +LLVM_ATTRIBUTE_USED // Fix gcc -flto builds. gcc's LTO (as of 4.8.1) don't sees + // references from inline asm. LLVM_LIBRARY_VISIBILITY void LLVMX86CompilationCallback2(intptr_t *StackPtr, intptr_t RetAddr) { intptr_t *RetAddrLoc = &StackPtr[1]; (However, I still can't link unittest programs, because of the use of anchor methods in CommandLine. I will take a look at it shortly.) /Patrik Hägglund -----Original Message----- From: Rafael Espíndola [mailto:rafael.espindola at gmail.com] Se...