search for: swapcontext

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 optimizers to begin handling these execution paths. The use cases for these operations, and things like coroutines built on top of them, will only increase in the future as developers look for ways to get more concur...

...ould be able to support "hard switching" in Stackless Python >> by adding a llvm.getcontextstacktop intrinsic.  If, as in Kristján's >> example, llvm.getcontext is used to create context A, and then >> execution continues until context B is created with >> llvm.swapcontext(B, A), the region of memory between >> llvm.getcontextstacktop(A) and llvm.getcontextstacktop(B) can be saved >> and later restored when B is resumed. > > Wait, what stack top does swapcontext get? I'd thought that A's and > B's stack top would be the same since the...

.... > 2. We should be able to support "hard switching" in Stackless Python > by adding a llvm.getcontextstacktop intrinsic.  If, as in Kristján's > example, llvm.getcontext is used to create context A, and then > execution continues until context B is created with > llvm.swapcontext(B, A), the region of memory between > llvm.getcontextstacktop(A) and llvm.getcontextstacktop(B) can be saved > and later restored when B is resumed. Wait, what stack top does swapcontext get? I'd thought that A's and B's stack top would be the same since they're executing on...

...; 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 (From the reply) > But any function call we perform after the > swapcontext() may trample the unsaved stack, if the source and destination stack positions > overlap. I'm having trouble visualizing that situation. Is there a "main" context that will handle all this saving and restoring of stacks? If so, does it actually share stacks with other contexts i...

...support "hard switching" in Stackless Python >>> by adding a llvm.getcontextstacktop intrinsic.  If, as in Kristján's >>> example, llvm.getcontext is used to create context A, and then >>> execution continues until context B is created with >>> llvm.swapcontext(B, A), the region of memory between >>> llvm.getcontextstacktop(A) and llvm.getcontextstacktop(B) can be saved >>> and later restored when B is resumed. >> >> Wait, what stack top does swapcontext get? I'd thought that A's and >> B's stack top would b...

...than the stack during the switch, but LLVM doesn't provide a way to do that. The cleaner way to do this is to switch to an intermediate stack scheduler context with its own stack, have it replace the stacks, and then switch to the target context back on the original stack. But that requires two swapcontext() calls, which seems less than idea performance-wise. 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 to do this that I'm missing? Jeffrey

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

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, 2...

...can be automatically applied to user-space context switches. The paper shows the results of many benchmarks, all of which show this model heavily outperforming existing models of context switching, in both speed and memory usage. For example, it mentions that the POSIX functions makecontext() and swapcontext() save a structure that’s 936 bytes in size (768 on my machine), but their model generates context switches that save only 8-80 bytes of CPU state, depending on which existing optimizations are able to apply to the specific context switch. In some cases, the entire context switch is reduced to 1 or...

...memory allocation going on "under the covers", or a requirement that a front-end do CPS conversion - it looks like later email has made this same point, so perhaps this is not being considered any longer. One thing I don't think I've seen mentioned so far is the interplay between swapcontext() and register allocation - I would hope a high performance implementation would exist that would only result in registers that are currently live being saved/restored at these points, not just a general save/restore of register state. _______________________________________________ LLVM Developer...

...ly within heap Python frames. Still, it would be nice to support this use case. Kenneth, I don't want to insist that the first version of this be both a floor wax _and_ a dessert topping, but is there a natural extension to supporting what Stackless needs that we could add later? It looks like swapcontext() simply repoints the stack pointer and restores the registers, while Stackless wants it to be able to allocate memory and copy the stack. Maybe that implies a "mode" argument? Alternately, Stackless could probably work with a segmented stack mechanism like Ian Taylor implemented in gcc...

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.

...VM, as far as I can tell). 2. We should be able to support "hard switching" in Stackless Python by adding a llvm.getcontextstacktop intrinsic. If, as in Kristján's example, llvm.getcontext is used to create context A, and then execution continues until context B is created with llvm.swapcontext(B, A), the region of memory between llvm.getcontextstacktop(A) and llvm.getcontextstacktop(B) can be saved and later restored when B is resumed. Of course that usage would throw a monkey wrench into a segmented stack scheme... it assumes that context stack areas actually behave like contiguous sta...

...s Wise via llvm-dev wrote: >> The paper shows the results of many benchmarks, all of which show this >> model heavily outperforming existing models of context switching, in >> both speed and memory usage. For example, it mentions that the POSIX >> functions makecontext() and swapcontext() save a structure that’s 936 >> bytes in size (768 on my machine), but their model generates context >> switches that save only 8-80 bytes of CPU state, depending on which >> existing optimizations are able to apply to the specific context switch. >> In some cases, the enti...

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

...stCases/Posix/coverage-direct.cc AddressSanitizer-mips64-linux :: TestCases/Posix/coverage-fork-direct.cc AddressSanitizer-mips64-linux :: TestCases/Posix/coverage.cc DataFlowSanitizer :: custom.cc DataFlowSanitizer :: propagate.c LeakSanitizer-AddressSanitizer :: TestCases/swapcontext.cc LeakSanitizer-AddressSanitizer :: TestCases/use_registers.cc LeakSanitizer-Standalone :: TestCases/swapcontext.cc LeakSanitizer-Standalone :: TestCases/use_registers.cc MemorySanitizer :: Linux/process_vm_readv.cc MemorySanitizer :: allocator_mapping.cc MemorySaniti...

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

...itizer-mips64-linux :: TestCases/Posix/coverage-fork-direct.cc > AddressSanitizer-mips64-linux :: TestCases/Posix/coverage.cc > DataFlowSanitizer :: custom.cc > DataFlowSanitizer :: propagate.c > LeakSanitizer-AddressSanitizer :: TestCases/swapcontext.cc > LeakSanitizer-AddressSanitizer :: TestCases/use_registers.cc > LeakSanitizer-Standalone :: TestCases/swapcontext.cc > LeakSanitizer-Standalone :: TestCases/use_registers.cc > MemorySanitizer :: Linux/process_vm_readv.cc >...

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

...t_table /root/SOURCE/ebtables-2.0.11/communication.c:709 This frame has 2 object(s): [32, 36) 'optlen' [96, 216) 'repl' <== Memory access at offset 216 overflows this variable HINT: this may be a false positive if your program uses some custom stack unwind mechanism or swapcontext (longjmp and C++ exceptions *are* supported) SUMMARY: AddressSanitizer: stack-buffer-overflow (/lib/x86_64-linux-gnu/libasan.so.5+0x68a0a) Shadow bytes around the buggy address: 0x100061895930: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x100061895940: 00 00 00 00 00 00 00 00 00 00 0...