search for: epilogues

On 16 January 2018 at 12:23, 陳韋任 <chenwj.cs97g at g2.nctu.edu.tw> wrote: > Do we have to emit directives in the epilogue, too? One of my test case fail > due to the directives in the epilogue have been executed. After removing > them from epilogue, the exception is caught as expected. Emitting directives in the epilogue is hard because the directives apply to all instructions

2018-01-16 18:18 GMT+08:00 Tim Northover <t.p.northover at gmail.com>: > On 15 January 2018 at 12:49, 陳韋任 via llvm-dev <llvm-dev at lists.llvm.org> > wrote: > > - CFI directives: > > > > This is for .eh_frame section. Basically all the targets insert CFI > > directives in FrameLowering, but I am not sure exactly when/where I > should > > do

2018-01-16 21:03 GMT+08:00 Tim Northover <t.p.northover at gmail.com>: > On 16 January 2018 at 12:23, 陳韋任 <chenwj.cs97g at g2.nctu.edu.tw> wrote: > > Do we have to emit directives in the epilogue, too? One of my test case > fail > > due to the directives in the epilogue have been executed. After removing > > them from epilogue, the exception is caught as

Hi! I am still working on the Win64 EH code and now have a pretty usable result. (The MC part is already posted to llvm-commits, the other part follows soon. If you are curious the whole patch is here: http://www.redstar.de/ldc/win64eh_all_20130524.diff.) However, in one case I have a problem with LLVM being too smart. Consider the following D code: void doIt() { printf("doIt:

 > These is metadata for epilogues (UWOP_EPILOG) but it is only available on Windows 8.1 and newer. I'm aware of this. I believe it is so sampling profilers can walk the kernel stack including through paged code -- i.e. the epilogue data is not paged, while the related epilogue code might be. Do you see it used, i.e. in usermod...

On 16 January 2018 at 13:41, 陳韋任 <chenwj.cs97g at g2.nctu.edu.tw> wrote: > bar: > > .cfi_def_cfa_offset 16 > epilogue > > _Unwind_Resume > > > > The lookup phase of exception handling is fine. However, something goes > wrong in cleanup phase. The reason is the unwinder evaluates CFI directives > until _Unwind_Resume, and `.cfi_def_cfa_offset

...e rbp and often is not.              There is also a notion of chaining the data. This is useful when       a function has "early out" paths that only change some non volatiles.              Also there is allowance for discontiguous functions.              Also there is no metadata for epilogues. If an exception occurs in an epilogue,       the runtime actually look at the code being run, detects it is an epilogue       and simulates it. As such, epilogue code generation is constrained.       (and breakpoints within epilogues mess things up!)              To repeat -- the unwindability is...

LOL - You mean he actually 'met' Newt Gingrich? How dare you not extend him credit!!! I mean seriously... For such a distinguished individual... Hey, not only have I met the heads of several multi-billion dollar corps, I have gotten absolutely blasted drunk with them. So I should get credit, a 40% discount, and your daughters phone number, right??? LOL Seriously, though. I think it

...ng > system to specify. > > 3.5 Interaction with Code Generation > The relatively simple and fixed size nature of the extended compact > unwind information > proposed here depends on observing certain restrictions on optimization > that might affect code in > prologues and epilogues. These restrictions were noted where relevant > throughout this section. > Here is a summary of those requirements: > > 1. Use of any preserved register must be delayed until all of the > preserved registers have > been saved. > 2. In the prologue of a function with a RBP-b...

...inker, image loader and exception handling system to specify. 3.5  Interaction with Code Generation The relatively simple and fixed size nature of the extended compact unwind information proposed here depends on observing certain restrictions on optimization that might affect code in prologues and epilogues. These restrictions were noted where relevant throughout this section. Here is a summary of those requirements:  1. Use of any preserved register must be delayed until all of the preserved registers have     been saved.  2. In the prologue of a function with a RBP-based frame, the two instructions...

Hi, On 15.04.2014 23:44, Vadim Chugunov wrote: > Hi, > I am curious - how does clang deal with epilogue-less functions that > result from _Raise_Exception being marked 'noreturn'? > I've also been playing with Kai's patch, and discovered that this tends > to greatly confuse Windows stack unwinder in cases when noreturn call is > at the end of a function, so

On Thu, Apr 9, 2009 at 4:34 PM, Anton Korobeynikov <anton at korobeynikov.info>wrote: > Hello, Aaron > > > How/where are function prologs and epilogs generated, is it bespoke C++ > code > > or TableGen generated ? > > > > If someone could point me in the right direction please. > Calling convention is really-really far from prologue/epilogue emission :)

Implementing tail call opt could look like the following: 0.)a fast calling convention (maybe use the current CallingConv::Fast, or create a CallingConv::TailCall) 1.) lowering of formal arguments like for example x86_LowerCCCArguments in stdcall mode we need to make sure that later mentioned CALL_CLOBBERED_REG is not used (remove it from available registers in callingconvention for

Hi all, I want to implement the Xor random canary, so I have to get the return address in the prologue and epilogue of the function. In the prologue 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 =

...ng > system to specify. > > 3.5 Interaction with Code Generation > The relatively simple and fixed size nature of the extended compact > unwind information > proposed here depends on observing certain restrictions on optimization > that might affect code in > prologues and epilogues. These restrictions were noted where relevant > throughout this section. > Here is a summary of those requirements: > > 1. Use of any preserved register must be delayed until all of the > preserved registers have > been saved. > 2. In the prologue of a function with a RB...

> From: Tim Northover via llvm-dev <llvm-dev at lists.llvm.org> > Emitting directives in the epilogue is hard because the directives > apply to all instructions after in program-counter order. So if you > have an epilogue in the middle of a function and emit CFI directives > saying the registers are back where they were then the unwinder will > think that applies to the

Hi Andrew, thanks for answering On Thu, Apr 15, 2010 at 3:35 PM, Andrew Lenharth <andrewl at lenharth.org>wrote: > On Thu, Apr 15, 2010 at 3:40 AM, Artur Pietrek <pietreka at gmail.com> wrote: > > Hi all > > Ups, I'm really sorry for that previous message, I've sent it by mistake. > > > > So let me write it once more. > > > > I've

Hi all, We're at the point in our port of OpenVMS to x86-64 that we're working on the unwind code.  The current ABI and the current codebase doesn't have enough support for true asynchronous unwinding from any point (most notably in the prologue/epilogue) in the code that OpenVMS needs.  We're working on a set of changes to the compact unwind information to handle the additional

...t; > > 3.5 Interaction with Code Generation > > The relatively simple and fixed size nature of the extended compact > > unwind information > > proposed here depends on observing certain restrictions on optimization > > that might affect code in > > prologues and epilogues. These restrictions were noted where relevant > > throughout this section. > > Here is a summary of those requirements: > > > > 1. Use of any preserved register must be delayed until all of the > > preserved registers have > > been saved. > > 2. In th...

Hi friendly LLVM Devs, I'm trying to understand the technical details of tail call optimization, but unfortunately I hit some issues that I couldn't figure out myself. So I tried the following two really simple functions: > extern void g(int*); > void f1() { > int x; > g(&x); > } > void f2(int* x) { > g(x); > } > It turns out that 'f1'