similar to: Altering the return address , for a function with multiple return paths

Yes, indeed! The SBCL lisp compiler (not llvm based) used to emit functions which would return either via ret to the usual instruction after the call, or else load the return-address from the stack, then jump 2 bytes later (which would skip over either a nop or a short jmp at original target location). Which one it used depended upon whether the function was doing a multi-valued return (in which

I recently examined a bug in a program, and it turned out that the customer was using the section attribute as a form of inline-assembly mechanism, with something like: __attribute__((section("sectionName\nasm\nasm\nasm"))) this was really ugly and not at all obvious where the problem originated. Is there any way of getting LLVM or CLang to validate the name used in the section

hi, list, i am making a llvm compiler for shader-like programs. as we known, shader programs are short and have less function calls. i found that i have to save/restore callee-saved register(CSR) in prolog and epilog. because I can violate ABI from driver(c code) and shader, i plan to append the attribute 'noreturn' to all shader functions. in PrologEpilogInserter.cpp, you can find that

Hi, I am having troubles in building xen unstable. make[3]: Entering directory `/data/xen/build/xen-unstable.hg-3.0-20060725.5/tools'' [ -f ioemu/config-host.h ] || \ (cd ioemu && sh configure --prefix=/usr) Install prefix /usr BIOS directory /usr/share/xen/qemu binary directory /usr/lib/xen/bin Manual directory /usr/share/man ELF interp prefix Source path

On Wed, Mar 23, 2011 at 03:37:02PM +0530, Sanjoy Das wrote: > I intend to start with the simplest possible approach - representing the > stack as a doubly linked list of _block_s, the size of each _block_ > being a power of two. This can later be modified to improve performance > and accommodate other factors. Blocks will be chained together into a > doubly linked list structure

hello everyone,recently I write a package for R call Julia through Julia C API https://github.com/armgong/RJulia now the package can do 1 finish basic typemapping, now int boolean double R vector to julia 1d-array is ok,and julia int32 int64 float64 bool 1D array to R vector is also ok. 2 R STRSXP to julia string 1D array and Julia string array to STRSXP is written but not sure it is correct or

On Mon, 2008-05-19 at 20:40 +0300, Pertti Kellomäki wrote: > The only hitch is that in the MCU world people expect to be > able to write interrupt handlers and the like in C... Most of the support that I have seen for this in other compilers amounts to custom calling conventions and preambles. Are you thinking of more than this?

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 =

Hello, I'm adding a new function attribute in clang and llvm for a backend I'm writing that treats prolog and epilogue code in a special way inside interrupt handlers, similar to what naked does. One way I've seen to do this is to add a new attribute type in Attributes.h, however to me it feels bad to add a target dependent attribute into this place which is very target independent.

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

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

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

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

Hi All! I will be applying to the LLVM project for this GSoC, and I wanted some preliminary sanity check on my project idea. I intend to implement split (segmented) stacks for LLVM (like we have in Go, and as being implemented for GCC [1]). A lot of what follows is lifted from [1]; I will progressively add more details as I get more familiar with the LLVM codebase. I intend to start with

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

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

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

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