<div dir="ltr"><div class="gmail_extra"><div>On Tue, Apr 19, 2016 at 1:18 PM, Filipe Cabecinhas <span dir="ltr"><<a href="mailto:filcab@gmail.com">filcab@gmail.com</a>></span> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">Thanks for proposing this. It seems like it might be an interesting<br>
tool for us too. But this proposal seems a bit hand-wavy, and I think<br>
it's missing some crucial info before we start heading this way.<br></blockquote><div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><br class="gmail-Apple-interchange-newline">At least for the tools you are currently starting to implement, it<br>would be nice to have some estimates and plans on what is going to<br>happen.<br></blockquote><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">I would actually like to see a small RFC about each tool and what the<br>plan (overhead/slowdown, pseudo-code for instrumentation, UX, ...) is<br>before starting to commit.<br></blockquote><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">I don't expect the plan to be very detailed, nor for everything to be<br>pinned down, of course. This seems to be a bit at a research stage,<br>and I'm totally ok with it. But would rather it not be as opaque as it<br>is now. The way the tools will report problems/data/etc, is important,<br>for example.<br></blockquote></div><div><br></div><div><div>The main response here is that these tools are in an exploratory stage and that what we are proposing is not a fixed list of tools but a framework within which we can build prototypes and refine them.  We do not know which ideas will work out and which ones will be abandoned.  In some cases, answers will not all be known until a prototype is in place to see how it behaves on large applications: we might need to add additional shadow metadata or additional instrumentation to produce the right amount of actionable output.  What we want to avoid is having to build prototypes out-of-tree until they are proven and polished and only then trying to commit large patches upstream.</div><div class="gmail_quote"><br></div></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">Do you have any estimates on memory overhead (both memory usage<br>
(+shadow), and code size) you expect? As well as estimated about the<br>
possible slowdown?<br></blockquote><div><br></div><div>The shadow memory for tools we are considering include 64:1, 4:1, and 1:1.  This is all within the ranges of existing sanitizers.  Each tool will have inlined instrumentation to update shadow memory on either every memory access or in some cases just focusing on the heap; I do not have a number for code size expansion. The slowdown ranges were in the original email: 2x-5x.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><span>> We are proposing the name EfficiencySanitizer, or "esan" for short, to refer<br>
> to this suite of dynamic instrumentation tools for improving program<br>
> efficiency.  As we have a number of different tools that share quite a bit<br>
> of their implementation we plan to consider them sub-tools under the<br>
> EfficiencySanitizer umbrella, rather than adding a whole bunch of separate<br>
> instrumentation and runtime library components.<br>
<br>
</span>How much code is expected to be shared? Most? Similar to what the<br>
sanitizers already share?<br></blockquote><div><br></div><div>More than what the existing sanitizers share.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
Do we expect the shadow memory mapping to be (mostly) the same among<br>
all esan's tools?<br></blockquote><div><br></div><div>Most will use a single mapping and single algorithm, but the scaledown will vary as mentioned.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
Do you already have an idea of a few tools + the type of code that<br>
would be shared (for example: "read/write instrumentation is mostly<br>
the same among these tools", or "generating reports for these tools is<br>
mostly the same", or something similar)?<br></blockquote><div><br></div><div>Instrumentation will be very similar (minor differences in shadow scaling and shadow metadata format), identical intrinsic handling, identical slowpath entries, identical libc interception, identical shadow management.  Reports are not fully explored.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><span>> While these tools are not addressing correctness issues like other<br>
> sanitizers, they will be sharing a lot of the existing sanitizer runtime<br>
> library support code.  Furthermore, users are already familiar with the<br>
> sanitizer brand, and it seems better to extend that concept rather than add<br>
> some new term.<br>
<br>
</span>Not the email to bike-shed the name, but I don't like "Efficiency"<br>
that much here :-)<br></blockquote><div><br></div><div>There were name discussions prior to the RFC and the conclusion was that there is just not going to be a single first-place choice for everyone.</div></div></div></div>