search for: swapcontexts

Right now the functionality is available, sometimes, from the C standard library. But embedded environments (often running a limited standard library) and server environments would benefit heavily from a standard way to specify context switches within a single thread in the style of makecontext/swapcontext/setcontext, and built-in support for these operations would also open the way for

On Sun, Apr 11, 2010 at 4:09 PM, Jeffrey Yasskin <jyasskin at google.com> wrote: > Kenneth Uildriks <kennethuil at gmail.com> wrote: >> As I see it, the context switching mechanism itself needs to know >> where to point the stack register when switching.  The C routines take >> an initial stack pointer when creating the context, and keep track of >> it from

Kenneth Uildriks <kennethuil at gmail.com> wrote: > As I see it, the context switching mechanism itself needs to know > where to point the stack register when switching.  The C routines take > an initial stack pointer when creating the context, and keep track of > it from there.  If we don't actually need to interoperate with > contexts created from the C routines, we have

...stack. But that > requires two swapcontext() calls, which seems less than idea > performance-wise. OK, I see you don't want to have a "main" context that does this and dispatches other contexts if it can be avoided. Compared to copying stacks, though, I'm not sure that two swapcontexts will be that bad, especially if we don't implement them as posix library function calls. > > Since the backend _can_ ensure that the relevant data is in machine > registers, do you think it makes sense to provide a swapcontext() that > also moves the stack? Or is there another way...

On Sun, Apr 11, 2010 at 2:41 PM, Kenneth Uildriks <kennethuil at gmail.com> wrote: > On Sun, Apr 11, 2010 at 4:09 PM, Jeffrey Yasskin <jyasskin at google.com> wrote: >> Kenneth Uildriks <kennethuil at gmail.com> wrote: >>> As I see it, the context switching mechanism itself needs to know >>> where to point the stack register when switching.  The C

On Sun, Apr 11, 2010 at 10:07 PM, Jeffrey Yasskin <jyasskin at google.com> wrote: > I'll forward your next draft back to the stackless folks, unless you > want to pick up the thread with them. Their reply: http://thread.gmane.org/gmane.comp.python.stackless/4464/focus=4475 Instead of @llvm.getcontextstacktop(%context), they want @llvm.getcurrentstacktop() so that they can copy

Hello- Shouldn't this catch swapcontext as well? Alistair On 26 May 2010, at 22:14, Dale Johannesen wrote: > > On May 26, 2010, at 2:05 PMPDT, Dan Gohman wrote: > >> vfork and getcontext have wildly platform-dependent semantics. >> Handling >> them conservatively is reasonable, even if some platforms don't need >> it. >> >> Dan >

I didn't see swapcontext in the list in gcc's special_function_p function... -bw On May 26, 2010, at 2:20 PM, Alistair Lynn wrote: > Hello- > > Shouldn't this catch swapcontext as well? > > Alistair > > On 26 May 2010, at 22:14, Dale Johannesen wrote: > >> >> On May 26, 2010, at 2:05 PMPDT, Dan Gohman wrote: >> >>> vfork and

Hi LLVM devs, I’d like to describe my problem, and then propose new features of LLVM which would solve it efficiently. I'm building a new statically-compiled programming language, and I plan on using LLVM as the backend. The language will have a runtime with cooperatively managed green threads (user-space "mini-threads", each with their own dynamically allocated stack). A single OS

I'm very interested in seeing support for stack/context switching in LLVM, if only for prototyping language ideas. I'm particularly interested in mechanisms that would make it possible to implement full asymmetric coroutines as described in "Revisiting Coroutines" (Moura & Ierusalimschy, Feb 2009 TOPLAS). From skimming the thread and looking at the llvm-stack-switch wiki, it

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

On Mon, Apr 12, 2010 at 6:15 AM, Kenneth Uildriks <kennethuil at gmail.com> wrote: > I created a wiki at http://code.google.com/p/llvm-stack-switch/ > > Right now I just copied and formatted the document as-is... I'll go > back over it with your comments in mind soon.  One more question, > which you can answer here or there: > >> Point 4 is a bit confusing.

Having read through Stackless Python's web pages a bit: 1. They're doing pretty much what I'd like to do, except that I don't want to be tied to a particular language and I'd like to be able to use the stack. (Also, stack use is inescapable with LLVM, as far as I can tell). 2. We should be able to support "hard switching" in Stackless Python by adding a

Sorry, I certainly didn't mean to be dishonest. I was just repeating one of the comparisons given by the research paper. Regardless, even setjmp() uses a structure of 148 bytes in size (on my machine). The main point is that with compiler support, many context switches can be easily reduced to just a few instructions and only 8 byte of memory, and even in the worst case they will outperform

On the other hand, stack manipulation really ought to be handled by the target, since only the target knows the details of how the stack is laid out to begin with. Also, if we have stack manipulation calls in the IR, optimization quickly becomes very difficult. Unless we just allow optimizers to ignore the stack manipulations and assume they're doing the "right" thing. On the

clang+llvm-3.8.0-rc3-x86_64-linux-gnu-debian8.tar.xz (sha1sum: 2dedc6136d7cfbac8348652c543887964d92393c) Native: All ok Cross compiling to MIPS: All ok clang+llvm-3.8.0-rc3-mips-linux-gnu.tar.xz (sha1sum: f286149dbb2ea7e194c5c3719b6cded476f6e65f) All ok (aside from non-regression failures in check-all). There were two kinds of check-all failure: * mips64 sanitizers. Not a regression since

Dear testers, Release Candidate 3 has just been tagged [1]. Please build, test, and upload to the sftp. If there are no regressions from previous release candidates, this will be the last release candidate before the final release. Release notes can still go into the branch. Thanks again for all your work! Hans [1] http://lists.llvm.org/pipermail/llvm-branch-commits/2016-February/009866.html

On Mon, Feb 29, 2016 at 2:20 AM, Daniel Sanders <Daniel.Sanders at imgtec.com> wrote: > clang+llvm-3.8.0-rc3-x86_64-linux-gnu-debian8.tar.xz (sha1sum: 2dedc6136d7cfbac8348652c543887964d92393c) > Native: All ok > Cross compiling to MIPS: All ok > > clang+llvm-3.8.0-rc3-mips-linux-gnu.tar.xz (sha1sum: f286149dbb2ea7e194c5c3719b6cded476f6e65f) > All ok

Hi, Is there any way to support either stack branching or heap-allocated stack frames in llvm? What I am after is non-preemptive threading support (as in Modsim, but I have also written a small library in asm to allow this in C), where a function can "suspend" itself and resume execution later. I was excited to find llvm as I thought it would be an excellent back end for a language

https://bugzilla.netfilter.org/show_bug.cgi?id=1432 Bug ID: 1432 Summary: ebtables ebtables-2.0.11 buffer overflow on getting kernel data ( ebtables compiled with address sanitizer) Product: netfilter/iptables Version: unspecified Hardware: x86_64 OS: Debian GNU/Linux Status: