similar to: TableGen operand question

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

Hi Nick, It is a pleasure to be in contact with the creator of the compact unwind approach! I can see how an array of 32-bit unwind blocks could be used to describe each distinct point within a function (within a prolog in particular). But then you end up with six or seven or more such blocks for a large percentage of functions, don't you? Seems like a lot of additional space for something

John and Ron, I developed the original compact unwind implementation for macOS 10.6 back in 2009. I tried to leave space in the design to support finer grain exception handling such as for asynchronous or for the shrink wrap optimization. The idea I had at the time was instead of having just one 32-bit compact unwind info per function, there could be an array of them each covering a different

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 been working for some time now on a backend for our CPU. However I > couldn't figure out how to implement some stuff. > I'd appreciate your help

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 =

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

You mean when I "explicity" use it by calling methods of register scavenger? Right now I'm just allocating virtual registers that will be resolved by the use of register scavenger and I'm also providing an override of the virtual method saveScavengerRegister. In Mips16, I have an extra mips 32 register (not usually very useful since it can only be used in a move instruction)

Hi Eric, Eric Christopher wrote: > Two things: > > a) I'm not against this Great! > b) So, what's your use case? I've got something I'm idly working on with > someone else where we want patchable targets in both prologue and > epilogue (and some other places...), and am thinking of how to make this > someone generic enough to build off of there. We

> Message: 3 > Date: Sun, 3 Jul 2016 17:49:50 -0700 > From: Michael Lewis via llvm-dev <llvm-dev at lists.llvm.org> > To: Hayden Livingston <halivingston at gmail.com> > Cc: llvm-dev <llvm-dev at lists.llvm.org> > Subject: Re: [llvm-dev] Status of stack walking in LLVM on Win64? > Message-ID: > <CAEm7p3svyOi6JU6r_RCCtRfGhTgTHeRw-SR0iD+9Edv2pi71Dw at

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 :)

I think most function redirection patching schemes are going to be mutually incompatible, so I'm not sure it makes sense to make this attribute a comma-separated list. I think Eric's and Dean's use case may be better addressed by a separate attribute. My recollection is that they want to add nop slides to the prologue and epilogue that can be hotpatched to enable and disable

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. Many thanks in advance, Aaron -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20090409/fb3336e4/attachment.html>

Hi Nick, Nick Johnson wrote: >> I'd like to generate this layout: >> >> 12(%ebp) - second function parameter >> 8(%ebp) - first function parameter >> 4(%ebp) - old %EIP (the function's "return address") >> 0(%ebp) - old %EBP (previous function's base pointer) >> -4(%ebp) - My language specific information

Hi Tim, Thank you for your reply. Actually, I already played with various target triples including what sys::getProcessTriple() returns when I tried to compile it on a Raspberry Pi 3 device. Yes, changing the triple to armv7-unknown-linux-gnueabi changes the emitted return instruction to 'bx lr'. But this is not the issue. Let me describe it based on an example I prepared to demonstrate

 > 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 usermode?  (where the pdata/xdata/code are all equally paged). It

Hello, find enclosed a first patch for adding tail call optimizations for thumb1 targets. I assume that this list is the right place for publishing patches for review? Since this is my first proposal for LLVM, I'd very much appreciate your feedback. What the patch is meant to do: For Tail calls identified during DAG generation, the target address will be loaded into a register by use

Hi guys, I am doing a hobby compiler using LLVM. I have a rather peculiar problem with the 'select' instruction, as far as I can see. Given this code: ************************************************ ; Run-time Library Definitions %Exception = type { i8 } define private %Exception* @Start(i1* %$result) #0 { prologue: store i1 true, i1* %$result br label %epilogue epilogue:

Thanks for looping me in Eric! If I was going to suggest anything here, I'd like to think about a more general approach than a very specific attribute like this. My preference is something like "patchable-function"="kind,kind,..." (if that's even possible). This allows us to have common infrastructure for being able to implement different kinds of function-level

On Thu, Jul 16, 2009 at 9:29 PM, Joshua Moore-Oliva<llvm-dev at chatgris.com> wrote: > To the list of modifications I need to be able to perform, add > > the ability to specify the ordering of local variables in the stack If you need specific locations for everything you're allocating on the stack, you should probably just use a continuation-passing style like the one mentioned

Hello all, currently the SPU backend does not handle big stack frames (>16*511 bytes) nicely. llc asserts on malformed machine instructions. (Assertion `MI->getOperand(OpNo).isImm() && "printDFormAddr first operand is not immediate") E.g. the function: define i32 @foo() nounwind { entry: %retval = alloca i32 %big_data = alloca [1000 x i32] store i32 3840, i32*