search for: epilogue

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 after in program-counter order. S...

...he directives are emitted in the prologue when the > registers actually get saved. Sometimes all in a bunch, sometimes > interspersed with the saves, but it usually doesn't matter which. As > you've discovered that happens in XYZFrameLowering ​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 remov ​ing them from epilogue, the exception is caught as expected. Also, the directives are also for debug purpose (.debug_frame), right? I guess I only have to make sure directives work for exception...

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 expected. > > Emitting directives in the epilogue is hard because the directives > apply to all instructions afte...

...on("Failure"); } finally { printf("doIt: finally\n"); } printf("doIt: end\n"); } The code after the throw statement is unreachable. The last instruction of the finally block is a resume. LLVM now removes the last printf call and the epilogue code because it is all dead code. In fact the last instruction generated for this function is a call to the unwind_resume library function. Unfortunately Windows 64bit requires the epilogue code to perform the stack unwinding. In this special case it is not dead code but another form of metada...

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

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 16` is the culprit. I think > this is what...

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

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

Hi John & Ron, I read through the proposal and had a couple of quick observations. 1. The proposed encoding assumes that the epilogue instructions always come at the end of the function -- or rather, just before the next function. If there is a stack protector __stack_chk_fail sequence, or there is NOP padding between functions, then the epilogue cannot be expressed. The proposed encoding allows for instructions scheduled befor...

Here is our proposal to extend/enhance the x86-64 compact unwind descriptors to fully describe the prologue/epilogue for asynchronous unwinding.  I believe there are missing/lacking CFI directives as well, but I'll save that for another thread. Asynchronous Compact Unwind Descriptors Ron Brender, VMS Software, Inc. Revised January 25, 2018 1  Introduction This document proposes means to extend so-called co...

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

...nfo>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 :) > So: > > 1. Calling conventions > Partly tablegen / partly C++ code. Look for > CodeGen/SelectionDAG/CallingConvLower.cpp, > Target/X86/X86CallingConv.td and around. Usually this code is run > during different phases of sdag lowering. > > 2. Prologue / epilog...

...the tailcallee is dynamic, not a TargetGlobalAddress or the like, lower a move CALL_CLOBBERED_REG tailcallee instruction else attach a TargetGlobalAddress or the like -the size of the stack adjustment the realtailcall would be a no op operation that makes sure that epilogue is lowered before it (looks like a call), remember that we have a real tail call (like setBytesToPopOnReturn() , a setIsRealTailCall()) in the targetlowering()) *else emit regular function call with same calling conventions 3.)lower of the return: *if we are dealing with a rea...

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 = CallInst::Create(Intrinsic::g...

...1) would be much simpler (like SHT_REL was widened to SHT_RELA). -Nick > On Jan 26, 2018, at 7:54 AM, John Reagan via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Here is our proposal to extend/enhance the x86-64 compact unwind > descriptors to fully describe the prologue/epilogue for asynchronous > unwinding. I believe there are missing/lacking CFI directives as well, > but I'll save that for another thread. > > > Asynchronous Compact Unwind Descriptors > Ron Brender, VMS Software, Inc. > Revised January 25, 2018 > > 1 Introduction > T...

> 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 rest of the func...

...how to implement some stuff. > > I'd appreciate your help with these. > > > > First thing is return address saving. To do that, first I have to copy it > to > > a general purpose register. I have no idea how to find an unused gpr > > register in emitPrologue/emitEpilogue. I've noticed that in other > backends > > RegScavenger is used for that purpose, but not from inside of those > methods. > > So my question is how could I get an unused register from inside of these > > methods? > > Do you have an API specified register where the...

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 cases (and some clearly OpenVMS-specific needs that others won't care about). We've noted that gcc seems to generate better asynchronous unwind info and has th...

...ened to SHT_RELA). > > -Nick > > > > > On Jan 26, 2018, at 7:54 AM, John Reagan via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > > > > Here is our proposal to extend/enhance the x86-64 compact unwind > > descriptors to fully describe the prologue/epilogue for asynchronous > > unwinding. I believe there are missing/lacking CFI directives as well, > > but I'll save that for another thread. > > > > > > Asynchronous Compact Unwind Descriptors > > Ron Brender, VMS Software, Inc. > > Revised January 25, 2018...

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'