search for: saved_ip

...ne will jump to a function similar to setup_new_block (setup_new_block_coroutine) which will work like setup_new_block, except: 1. It will first check if saved_stack is NULL. If it is NULL, it will allocate a new block and save it to saved_stack. It if isn't, it'll simply restore saved_sp, saved_ip. 2. In case a new block was allocated, it will pretty much do what setup_block does, after which it will adjust the SP to make space for the saved registers. The destroy_block procedure will also have to be a little different (mentioned below). There are four things (relevant to this discussion)...

...milar to > setup_new_block (setup_new_block_coroutine) which will work like > setup_new_block, except: > > 1. It will first check if saved_stack is NULL. If it is NULL, it will > allocate a new block and save it to saved_stack. It if isn't, it'll > simply restore saved_sp, saved_ip. > > 2. In case a new block was allocated, it will pretty much do what > setup_block does, after which it will adjust the SP to make space for > the saved registers. > > The destroy_block procedure will also have to be a little different > (mentioned below). > > There are...

...new_block (setup_new_block_coroutine) which will work like >> setup_new_block, except: >> >> 1. It will first check if saved_stack is NULL. If it is NULL, it will >> allocate a new block and save it to saved_stack. It if isn't, it'll >> simply restore saved_sp, saved_ip. >> >> 2. In case a new block was allocated, it will pretty much do what >> setup_block does, after which it will adjust the SP to make space for >> the saved registers. >> >> The destroy_block procedure will also have to be a little different >> (mentioned...

..._block_coroutine) which will work like >>> setup_new_block, except: >>> >>> 1. It will first check if saved_stack is NULL. If it is NULL, it will >>> allocate a new block and save it to saved_stack. It if isn't, it'll >>> simply restore saved_sp, saved_ip. >>> >>> 2. In case a new block was allocated, it will pretty much do what >>> setup_block does, after which it will adjust the SP to make space for >>> the saved registers. >>> >>> The destroy_block procedure will also have to be a little diffe...

On Sun, Apr 10, 2011 at 4:16 PM, Chris Lattner <clattner at apple.com> wrote: > > On Apr 10, 2011, at 2:45 PM, Talin wrote: > > I wonder - would something like this allow for multiple stacks for a single > thread? I'm thinking of something like continuations / fibers / green > threads, which would be very handy. > > > I haven't looked at the proposal, but

On Apr 10, 2011, at 2:45 PM, Talin wrote: > I wonder - would something like this allow for multiple stacks for a single thread? I'm thinking of something like continuations / fibers / green threads, which would be very handy. I haven't looked at the proposal, but yes, this would be very useful functionality for LLVM to provide. -Chris > > On Wed, Mar 23, 2011 at 3:07 AM,

This series consists of improvements to Xen''s ability to print traces of its own stack, and specifically for the stack overflow case to be able to use frame pointers in a debug build. I have dev tested the series in debug and non-debug cases, with and without memory guards, and I believe that all the stack traces look correct (given the available information Xen has), and that the

...ection describes the proposed implementation in more detail. ** The block The block is a chunk of memory, whose size is a power of two (in bytes). It has four words reserved in the beginning of the block: 1. previous - Pointing to the previous block. 2. next - Pointing to the next block. 3. saved_ip - The original return address back to the callee. 4. saved_sp - The value of the SP when this block was created. ** Changes to the function prologue In its prologue, a function will check whether the current block has enough stack space. This is easily done for function which use a fixed amoun...

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

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