similar to: [LLVMdev] LLVM/Clang research questions

Hi Brent, LLVM supports segmented stacks, I suggest you do a case insensitive grep for segmented.stack in the source code (the . is to match any character). Ciao, Duncan. On 03/06/13 00:35, Brent Gregory Roth wrote: > Greetings, > > First, my apologies if I have incorrectly used any of these lists. > > I'm sending this email in order to get some help on where in the >

Hi Duncan, Are the segmented stacks actually on separate memory segments? My intended purpose for placing different datatypes on separate stacks is such that memory accesses to one datatype won't be allowed to overflow to another datatype. If they aren't, in fact, on separate memory segments, are you aware of a way to place a non-readable/-writable segment in between two other stack

Hi Duncan, It doesn't appear to be what I'm looking for as there is copying of the old stack to the new stack. Additionally, according to the LLVM docs on segmented stacks (http://llvm.org/releases/3.0/docs/SegmentedStacks.html) the stacklings are allocated memory from the heap. Since this places them all on the same memory segment, a read/write from one stackling could technically

Hi Brent, On 03/06/13 14:32, Brent Gregory Roth wrote: > Hi Duncan, > > Are the segmented stacks actually on separate memory segments? My intended > purpose for placing different datatypes on separate stacks is such that memory > accesses to one datatype won't be allowed to overflow to another datatype. > > If they aren't, in fact, on separate memory segments, are you

Hi Brent, You're correct. The segmented stack model is intended for performance, not security. Its goal is to allow lightweight threads to be very cheaply allocated and destroyed. For your model, you would most likely want to use different address spaces for the different memory types. Currently, clang does not allow you to define the address space of variables with automatic storage

Sorry for the delay in responding. On Mon, 13 Jun 2011, Rafael Avila de Espindola wrote: > On 11-06-02 07:47 PM, Peter Lawrence wrote: >> Guys, >> regarding alloca. >> >> not only are exceptions a problem here, but just plain old "longjmp". > > Yes, > On IRC Sanjoy pointed out that it should be possible to handle this by > changing longjmp. I am

On Thu, Jun 23, 2011 at 03:21:58PM -0400, Brian Hurt wrote: > Segmented stacks are exciting to me, but only if the stacklets can be > freed. Here's why: if segmented stacks allow for "infinite" stacks, tail > call optimization becomes a lot less important in functional languages- > still useful, but not live or die. We discussed this on IRC a while ago. IMHO it is

Hello, If I want implement other address spaces (for x86), can I modify my back-end (clang) to support other address spaces (at least two data segments, two heaps, and two stacks? How will be the mechanism? For example, for256/257, I see two reference points (FS and GP). Would I need to specify a different reference to each memory region? Where is the best site to add the modifications? Thanks

Hi llvmdev! I've been working on implementing support for segmented stacks in LLVM (towards GSoC '11). Currently I'm working on adding intrinsics for coroutines. The problem is this: Till now I had been depending on libgcc for runtime support (and was being 100% libgcc compatible in the process). However, since all the stack allocation routines in libgcc depend on TLS variables to

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

I took the liberty of forwarding this to the Stackless Python list, since they switch stacks, and I got a response at http://thread.gmane.org/gmane.comp.python.stackless/4464/focus=4467. The upshot is that they really need the ability to allocate only a tiny amount of space for each thread and grow that as the thread actually uses more stack. The way they accomplish that now is by copying the

Hi llvm-dev! I have attached the current state of my GSoC work in patches [1] for review; this currently allows LLVM to correctly handle functions running out of stack space and variable sized stack objects. Firstly, since I think it is better to get things merged in small chunks, I'd like to have some specific feedback on where my work stands in terms of mergeability. Secondly, I had been

On Wed, Mar 20, 2013 at 5:21 PM, Timur Iskhodzhanov <timurrrr at google.com>wrote: > 2013/3/20 Timur Iskhodzhanov <timurrrr at google.com>: > > Anton, > > > > [+Eric, Nick, > > the e-mail thread context has been broken a few times, so you should > > probably look at the llvmdev archives. > > It all starts here: > >

Hi all! Now that LLVM has support for a larger attribute set, I think it is a good idea to add one that stops LLVM from generating segmented stacked version of a function. While implementing it, I ran into an issue: Currently, with segmented stacks enabled, LLVM sets the action for DYNAMIC_STACKALLOC to Custom, and lowers it into native X86 code. However, if a function has the nosegmentedstack

Current set of patches for my work on segmented stacks. Go / dragonegg seems to work when using this code (I still haven't run any rigorous tests yet). Thanks! (Also on https://github.com/sanjoy/LLVM/tree/segmented-stacks) -- Sanjoy Das http://playingwithpointers.com -------------- next part -------------- A non-text attachment was scrubbed... Name:

On Thu, Jul 14, 2011 at 9:07 AM, Sanjoy Das <sanjoy at playingwithpointers.com>wrote: > Hi llvm-dev! > > I have attached the current state of my GSoC work in patches [1] for > review; this currently allows LLVM to correctly handle functions running > out of stack space and variable sized stack objects. > > Firstly, since I think it is better to get things merged in

Guys, regarding alloca. not only are exceptions a problem here, but just plain old "longjmp". -Peter Lawrence. On Jun 1, 2011, at 10:00 AM, llvmdev-request at cs.uiuc.edu wrote: > ------------------------------ > > Message: 4 > Date: Tue, 31 May 2011 16:55:07 -0400 > From: Rafael Avila de Espindola <rafael.espindola at gmail.com> > Subject: Re:

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 Sanjoy, > Now that LLVM has support for a larger attribute set, I think it is a > good idea to add one that stops LLVM from generating segmented stacked > version of a function. why? If some functions have segmented stacks, don't all functions called by it need segmented stacks too? Ciao, Duncan. While implementing it, I ran into an issue: > > Currently, with

I suggested to our Homeowners Association that we begin a Private Forum (phpBB) and web site. That suggestion has been well received and we will proceed with that. Now, I have become involved in a much more complex and important project, which is Video Surveillance, for the entrance to our subdivision. I Googled and found two (2) things for Linux that seem to be OK: (a) ZoneMinder