similar to: [LLVMdev] How to get the return address on the stack on LLVM

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. >

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

Hi all, I am master student in Edinburgh, UK. I am doing my MSc project with LLVM compiler and I have to modify LLVM to implement the StackGuard with a XOR random Canary. However, I am not familiar with LLVM. My problem is that I want to XOR the random canary word with the return address which are both 32 bits. I found a method called SimplifyXorInst(Value *, Value *, const TargetData

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 "filled bands" part of xYplot of the Hmisc package, is there a way to have multiple bands with multiple lines? or does it just allow one for now? So I had an example bit ago had a made up line and CI, now if I wanted to make a second line with a CI filled in can I put them on the same plot? x<-seq(1,10,1) y<-seq(1,10,1) ci<-y*.10 ciupper<-y+ci

On Dec 8, 2009, at 3:31 PM, Jakob Stoklund Olesen wrote: > > On Dec 8, 2009, at 11:33 AM, Evan Cheng wrote: > >> This caused a massive slow down to post-ra scheduler (llc -O3 on x86, -O2 on ARM). I'm going to revert it for now until it has been addressed. > > Probably caused by this member: > > /// KillIndices - The index of the most recent kill (proceding

Hi I want to write a FunctionPass to insert some code before return. Funcion: .. .. .. 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

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

I have something like this on my code :- vector<Value*> args3; args3.push_back(instr->getOperand(0)); //where 'instr' is store instruction Now when I check the Type of instr->getOperand(0). It varies to i32 and i64, depending on the operand(0) of instruction. Due to which my vector<Value*> has different Type of Value*. How can I convert i32 to i64 type before pushing

This caused a massive slow down to post-ra scheduler (llc -O3 on x86, -O2 on ARM). I'm going to revert it for now until it has been addressed. Evan On Dec 7, 2009, at 11:39 AM, Dan Gohman wrote: > > On Dec 7, 2009, at 11:15 AM, Pekka Jääskeläinen wrote: > >> Here's the actual patch, sorry ;) > > Applied in r90789. > > Dan > > >

Hi folk, I'm writing a set of small C code to verify whether my pass handle some instruction correctly. One of the instruction I want to test is "va_arg", but compiling my variadic function does not generate any va_arg instruction. Is va_arg deprecated? Will va_arg instruction ever be generated by any front-end? The source code and llvm instructions are appended as follows. the

I have a question about the performance of the implementation of the stack protector in LLVM. Consider the following C program: ===== void canary() { char buf[20]; buf[0]++; } int main() { int i; for (i = 0; i < 1000000000; ++i) canary(); return 0; } ===== This should definately run slower when stack protection is enabled, right? I have measured the runtime of

Hello, This patch was reverted and the revert was forgotten to be undone after the performance regression it introduced was fixed. Can someone please revert it back (i.e. increase the max physreg size to 16K or even better to 32K) to enable us to experiment with large register number machines again? :) It was this trivial patch: Index: include/llvm/Target/TargetRegisterInfo.h

If you compile this with optimizations, then the 'canary()' function should be totally inlined into the 'main()' function. In that case, the cost of the stack protectors will be very small compared to the loop. -bw On Mar 9, 2012, at 2:52 AM, Job Noorman <jobnoorman at gmail.com> wrote: > I have a question about the performance of the implementation of the stack >

I'm wrapping a function in R and I want to record all the arguments passed to it, including default values and missing values. I want to be able to snoop on function calls in sourced scripts as part of a unit testing framework. I can capture the values fine, but I'm having trouble evaluating them as if `force()` had been applied to each of them. Here is a minimal example: f0 <-

Hi, anybody have any ideas on this ? I have two sequences of proportions. Due to conventions in my field, I need to produce a linear correlation between the two. Each sequence of proportions are based upon differing numbers of observations (although within a sequence the number of observations may not fluctuate too much) so it may be necessary/advisable to variance stabilize. Is their a best

Neal, FYI, my group has added a flag to llvm-gcc for emitting the va_arg instruction (instead of lowering in the front-end), and we also have an implementation of the VAARG instruction for X86-64. (which is currently not implemented in the LLVM backend). Both of these things will be sent upstream to LLVM soon, pending some more testing and review. If you are dire need of these features now, I

I'm trying to add arguments to the AIC method for some classes -- things like weights=TRUE to calculate AIC weights corr=TRUE, nobs to calculate AICc delta=TRUE to put a delta-AIC column in the output. The problem is that AIC is defined as AIC(object, ..., k=2) where k is the constant associated with the penalty term and ... is a list of objects that will have their AICs calculated

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

(Sorry 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