similar to: [LLVMdev] Adding a stack probe function attribute

The point of this is to cheaply detect all stack overflows using a guard page. For a guard page to actually detect all stack overflows, we need to ensure that the code touches each page of the stack in the right order, otherwise it could skip the guard page and write outside the stack. That is very bad for languages such as Rust which provides memory safety, so it currently does an explicit

Yeah, the function attributes section of LangRef is a reasonable place to put stuff like this: http://llvm.org/docs/LangRef.html#function-attributes I think we should add this. I also know that LLILAC needs something like this as well. I propose the following: - Add a string attribute called "stack-probe-symbol"="foo". - The presence of this attribute indicates that stack

On Fri, Aug 1, 2014 at 11:12 PM, Philip Reames <listmail at philipreames.com> wrote: > Thanks for the explanation. I'm used to hearing the term "stack banging" > used for this mechanism, but I understand your objective. > > I believe having a general mechanism here would be valuable, but only if > the implementation doesn't make assumptions about runtime

Since David Majnemer doesn't seem overly eager to merge my patches, let's see if we can't figure things out here. I noticed a string function attribute appeared in LangRef.rst, would that be the correct place to document this? For reference: http://reviews.llvm.org/D9653 http://reviews.llvm.org/D9654 http://reviews.llvm.org/D9858 On Wed, Aug 6, 2014 at 5:34 PM, John Kåre Alsaker

Would the __probestack functions be a suitable addition to compiler-rt? Does it already have __chkstk or is that provided by something else on Windows? I noticed that libgcc implemented them in cygwin.S. On Mon, Aug 4, 2014 at 9:08 PM, Philip Reames <listmail at philipreames.com> wrote: > > On 08/01/2014 05:38 PM, John Kåre Alsaker wrote: > > On Fri, Aug 1, 2014 at 11:12 PM,

I updated http://reviews.llvm.org/D4717 and also wrote an __probestack implementation: https://github.com/Zoxc/compiler-rt/compare/llvm-mirror:master...stprobe Which instruction would be the preferable one to probe with? I used OR since that's what GCC/libgcc does, but I don't see why that would be better than a write. On Tue, Aug 5, 2014 at 7:34 PM, Reid Kleckner <rnk at

On Tue, Jul 28, 2015 at 2:25 AM, John Kåre Alsaker < john.mailinglists at gmail.com> wrote: > On Tue, Jul 28, 2015 at 12:44 AM, Reid Kleckner <rnk at google.com> wrote: > > Yeah, the function attributes section of LangRef is a reasonable place to > > put stuff like this: > > http://llvm.org/docs/LangRef.html#function-attributes > I'll see if I can't

On Tue, Jul 28, 2015 at 12:44 AM, Reid Kleckner <rnk at google.com> wrote: > Yeah, the function attributes section of LangRef is a reasonable place to > put stuff like this: > http://llvm.org/docs/LangRef.html#function-attributes I'll see if I can't sneak something in there. > > I think we should add this. I also know that LLILAC needs something like > this as

Since Rust references usually never aliases it would be nice if we could exploit this for code generation. One idea I had to improve alias analysis is to insert metadata on pointer loads. !inheritalias could be added to load instructions to indicate that if we know all the aliases of the pointer we load from, then we also know all the aliases of the pointer value loaded. Given that pointer loads

I started to implement inlining of the stack probe function based on Microsoft's inlined stack probes in https://github.com/Microsoft/llvm/tree/MS. Do we know why the stack pointer cannot be updated in a loop (which results in ideal code)? I noticed that was commented in Microsoft's code. I suspect this is due to debug or unwinding information, since it is allowed on Windows x86-32. I

Phabricator seems to like to send emails with zero content to the list with relatively high frequency, like this: > From: Ikhlas Ajbar <iajbar at codeaurora.org> > Subject: Re: [PATCH] Remove unused function HasPICArg(). > To: iajbar at codeaurora.org, bcahoon at codeaurora.org > Cc: llvm-commits at cs.uiuc.edu > Date: Tue, 19 May 2015 18:29:30 +0000 (6 hours, 21 minutes, 32

On Tue, Jul 28, 2015 at 6:34 PM, Reid Kleckner <rnk at google.com> wrote: > On Tue, Jul 28, 2015 at 2:25 AM, John Kåre Alsaker > <john.mailinglists at gmail.com> wrote: >> >> On Tue, Jul 28, 2015 at 12:44 AM, Reid Kleckner <rnk at google.com> wrote: >> > Yeah, the function attributes section of LangRef is a reasonable place >> > to >>

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

Anton, What do you think? 2013/3/20 Eric Christopher <echristo at gmail.com>: > > > > 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

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: > http://lists.cs.uiuc.edu/pipermail/llvmdev/2012-October/053961.html ] > > So I've decided to make a new attempt to fix this issue. > >

Hi Timur, I myself find the name "Win32" pretty confusing and easy to misuse (especially for someone who assumes that windows == msvc). After all mingw and cygwin is also win32. Maybe we should rename it into isTargetMSVC or something like this? On Wed, Mar 27, 2013 at 6:26 AM, Timur Iskhodzhanov <timurrrr at google.com> wrote: > Anton, > > What do you think? > >

Similar to what I just did for OCaml (this IS an API break, requiring recompilation of any existing Rust plugin), and done because I want to add fast_zero support to both languages as part of my upcoming fast zero series. Figuring out how to get extents working was hard enough that I punted that, still. Eric Blake (2): rust: Implement can_cache rust: Add support for dynamic .thread_model

Add an overview libnbd-rust(3) man page pointing to the real documentation. This is like OCaml & Golang. When reviewing the real rustdocs I noticed they basically converted the man pages into plain text, resulting in lots of problems such as internal links not working, no `code` annotations, etc. So I wrote a simple POD to rustdoc translator. It is by no means perfect, but it fixes many of

On Thu, Jun 27, 2019 at 05:06:04PM +0900, Hiroyuki Katsura wrote: > From: Hiroyuki_Katsura <hiroyuki.katsura.0513@gmail.com> > > --- > generator/rust.ml | 13 ++++++++--- > run.in | 9 ++++++++ > rust/Cargo.lock | 6 +++++ > rust/Cargo.toml | 4 +--- > rust/tests/010_load.rs