search for: returnaddress

...ogue of the function, before I insert into the canary on the stack, I can get the return address by: ConstantInt* ci = llvm::ConstantInt::get(Type::getInt32Ty(RI->getContext()), 0); Value* Args1[] = {ci}; CallInst* callInst = CallInst::Create(Intrinsic::getDeclaration(M, Intrinsic::returnaddress), &Args1[0], array_endof(Args1), "Call Return Address", InsPt); CallInst will get the return address and it works. While, in the epilogue of the function, due to the canary has been inserted. I write the similar code: ConstantInt* ci2 = llvm::ConstantInt::get(Ty...

On 7/26/11 5:37 PM, Xueying ZHANG wrote: > Hi John, > > Thanks for your reply! I'm CC'ing this to the list in case anyone knows why you're seeing this behavior. > > Now, I know the different between llvm.returnaddress(0) and > llvm.returnaddress(1). I modify the StackPortector.cpp and I just want > to get value of the return address stored on the stack. > > But when I call llvm.returnaddress(0) twice. For the first time, it > goes to the correct address which storing return address. Fascinati...

...n: .. .. .. mov eax,[esp] cmp eax,0x12345678 je 0x12345678 ret (maybe stack will not balance) I wonder that can I get the return address at llvm ir level? I use IRBuilder to CreateICmpEQ and CreateCondBr. but I don't how to get the value of return addrss. I have found there is a Intrinsic::returnaddress. Is Intrinsic::returnaddress can help me? I don't konw how to use Intrinsic::returnaddress because few files use this intrinsic. Thanks -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180905/6b40c861/a...

Hi all, I want to add some functionalities to Stack protection of llvm by modifying the file StackPrtoector.cpp under llvm/src/lib/CodeGen. However, I encounter some problems here. Here is my problem: I want to call the function Intrinsic::returnaddress with the same parameter twice in a function. However, llvm will optimize this process automatically by storing the result from the first call in the local stack, then use this value for the second call instead of calling the function again. However, I do want this function to be called twice exactl...

Hi all, I want to add some functionalities to Stack protection of llvm by modifying the file StackPrtoector.cpp under llvm/src/lib/CodeGen. However, I encounter some problems here. Here is my problem: I want to call the function Intrinsic::returnaddress with the same parameter twice in a function. However, llvm will optimize this process automatically by storing the result from the first call in the local stack, then use this value for the second call instead of calling the function again. However, I do want this function to be called twice exactl...

To my knowledge that intrinsic IS generated by frontends like Clang when using _builtin_return_address(), i could be wrong though Zhang > 在 2018年9月5日，10:47，Bekket McClane via llvm-dev <llvm-dev at lists.llvm.org> 写道： > > and

...rry for the 2nd email Eli, I forgot to reply-all). > I'm not following how explicitly representing the return address of a call in the IR before isel actually solves any relevant issue. We already pass the return address implicitly as an argument to every call; you can retrieve it with llvm.returnaddress if you need it. Unfortunately the @llvm.returnaddress intrinsic does not solve the problem, as it only reads the return address pushed onto the LLVM stack by a call. We would then need a way to move the LLVM stack pointer back to where it was before the call, because a CPS call _must_ not grow th...

Hello > In the prologue of the function, before I insert into the canary on > the stack, I can get the return address by: Note that there is no epilogue and prologue at IR level :) > But it does not work this time. I cannot get the return address. > What is problem? How can I get the return address? Thank you! What is the problem? It seems you're getting the return address via

+nlewycky On Mon, Nov 17, 2014 at 9:36 AM, Volodymyr Kuznetsov <vova.kuznetsov at epfl.ch > wrote: > Hi Kostya, > > On Sat, Nov 15, 2014 at 1:53 PM, Volodymyr Kuznetsov < > vova.kuznetsov at epfl.ch> wrote: > > Do you think moving the pass to lib/Transform/Instrumentation but > > scheduling it during code generation would make sense ? If so, we'll >

...re a clang option similar to -finstrument-functions for code blocks? Alternatively, I could manually insert the code to the IR .ll file. I see the generated .ll use the following function when -finstrument-functions is enabled. Is there an equivalent function for code blocks? %1 = call i8* @llvm.returnaddress(i32 0), !dbg !10 -- Regards, Peng

Misha Brukman wrote: > >>1. Opcodes and intrinsics >> > That's not really correct. The intrinsics such as llvm.frameaddress and > llvm.returnaddress have no equivalents in LLVM opcodes -- the meaning of > the intrinsics is specifically machine-dependent, and LLVM (and its > opcodes) are machine-independent, so there is no valid interchange of > these intrinsics with any combination of LLVM opcodes. > Yes, I understand that those i...

...acronyms) by these categories. I'm excluding here externally-defined terms (e.g. llvm.va_start): No separators (except for the initial namespace prefix): @llvm.gcroot @llvm.gcread @llvm.gcwrite @llvm.experimental.stackmap @llvm.experimental.patchpoint @llvm.experimental.gc.statepoint @llvm.returnaddress @llvm.frameaddress @llvm.localescape @llvm.localrecover @llvm.stacksave @llvm.stackrestore @llvm.pcmarker @llvm.readcyclecounter @llvm.bitreverse @llvm.eh.begincatch @llvm.eh.endcatch @llvm.eh.padparam @llvm.stackprotector @llvm.stackprotectorcheck @llvm.objectsize @llvm.donothing Words wi...

...any efficient solution short of making the backend aware of object pointer types. i.e. Machine operands need to carry these types. For stack walking, what do you need in addition to DWARF unwind? Or is generating correct unwind tables the problem? I'm not sure what stack intrinsics you mean... returnaddress and frameaddress? They don't always work if you provide the necessary target options? It almost sounds like you want more control than libunwind provides? Or do you want more efficiency? > Light-weight coroutines would be a "nice to have", as would better concurrency primitives....

Hi, I am trying to understand what should be the expected behavior of __builtin_return_address(0) when inlining has happened. So, the GCC doc from https://gcc.gnu.org/onlinedocs/gcc/Return-Address.html says: (I used GCC doc because I could not find equivalent Clang/LLVM builtin doc) When inlining the expected behavior is that the function returns the address of the function that is returned

...insics include debugging support, etc. > As I understand it, compilation passes can both lower intrinsics into > opcodes and also replace opcode sequences, so in the end some of them > are interchangeable. That's not really correct. The intrinsics such as llvm.frameaddress and llvm.returnaddress have no equivalents in LLVM opcodes -- the meaning of the intrinsics is specifically machine-dependent, and LLVM (and its opcodes) are machine-independent, so there is no valid interchange of these intrinsics with any combination of LLVM opcodes. The llvm.memcpy intrinsic can be lowered onto an ex...

Hi, I've been having some trouble implementing a new intrinsic for LLVM and I was wondering if someone might know the answer. LLVM has an llvm.returnaddress intrinsic, but for a specific project, I need to be able to modify the return address of a function as well, so I'm implementing a new intrinsic: def int_setreturnaddress : Intrinsic<[], [llvm_i32_ty, llvm_ptr_ty], []>; And I'm using it as follows: B.CreateCall2( Intrinsic::get...

On Mon, 25 Oct 2004, Marc Ordinas i Llopis wrote: > Misha Brukman wrote: > >>1. Opcodes and intrinsics > >> > > That's not really correct. The intrinsics such as llvm.frameaddress and > > llvm.returnaddress have no equivalents in LLVM opcodes -- the meaning of > > the intrinsics is specifically machine-dependent, and LLVM (and its > > opcodes) are machine-independent, so there is no valid interchange of > > these intrinsics with any combination of LLVM opcodes. > > > > Ye...

Hi everybody, I'm currently looking at LLVM as a possible back-end to a dynamic programming system (in the tradition of Smalltalk) we are developing. I have read most of the llvmdev archives, and I'm aware that some things are 'planned' but not implemented yet. We are willing to contribute the code we'll need for our project, but before I can start coding I'll have to

...mail Eli, I forgot to reply-all). >> >>> I'm not following how explicitly representing the return address of a call in the IR before isel actually solves any relevant issue. We already pass the return address implicitly as an argument to every call; you can retrieve it with llvm.returnaddress if you need it. >> >> Unfortunately the @llvm.returnaddress intrinsic does not solve the problem, as it only reads the return address pushed onto the LLVM stack by a call. We would then need a way to move the LLVM stack pointer back to where it was before the call, because a CPS call _...

After working with LLVM for several years now, one problem that remains unsolved is how to generate a stack backtrace for exceptions. My basic approach is simple: I have two different exception personality functions, a "lightweight" one that just does the bare minimum needed to handle exception, and a "capturing" one that (ideally) records the call frame information as it