<div dir="ltr"><div>[Sorry for delay, I was OOO. ]<br></div><div>+kuba, who did something related in the past. (<a href="http://llvm.org/viewvc/llvm-project?view=revision&revision=218538">http://llvm.org/viewvc/llvm-project?view=revision&revision=218538</a>)</div><div><br></div><div>My major concern is the added complexity and code maintenance cost. </div><div>You are trying to implement a feature for which I never felt any need, </div><div>so for me this sounds like "huge extra complexity for no benefit".</div><div>Obviously, since you are working on it, your users need it (or you think they do :).<br></div><div><br></div><div>I am not enthusiastic but let's look at the individual patches.</div><div>Some thoughts: </div><div>  * if something is not asan-specific, put it into sanitizer_common so that we can reuse it in ubsan/tsan/msan. </div><div>  * try to avoid any extra memory allocation or system calls while reporting a bug to stderr. </div><div>    Keeping the bug reporting machinery reliable is the 1-st priority. </div><div>  </div><div>--kcc </div><div><br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Jul 4, 2016 at 10:09 AM, Filipe Cabecinhas via llvm-dev <span dir="ltr"><<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>></span> wrote:<br><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">Hi all,<br>
<br>
As we all know, ASan prints all diagnostics information to stderr. It<br>
also has some API to get<br>
information about addresses, etc (useful for debugging), which prints<br>
information to stderr.<br>
<br>
These features require a live process, and the ability to call<br>
functions in the process. It also<br>
forces a user to do multiple target calls to run functions, which<br>
might be slow (or impossible, in<br>
the case of core dumps). The API functions like __asan_get_report_*()<br>
also aren't as useful as they should, since they only work for generic<br>
errors.<br>
<br>
We would like to make it easier to:<br>
  - Embed an ASan error in a core dump, with all relevant information<br>
(basically, it should be<br>
possible to implement the printing mechanism with the information<br>
added to the core dump, without<br>
knowing about ASan internals);<br>
  - Have a debugger (possible running on another host) be able to get<br>
all the information available<br>
through ASan API in a structured way.<br>
<br>
We will be proposing patches to implement this. I'm thinking of doing<br>
it piecewise by starting with<br>
simple API functions like `__asan_describe_address(void *)`. We'd add<br>
a function to populate a<br>
struct, and then reimplement __asan_describe_address in terms of that function.<br>
<br>
For the core dump/minimize number of calls scenario, we'd like to have<br>
one single "error<br>
description" structure, which we could add to a core dump via system<br>
API, or have the debugger read<br>
the whole structure once through an ASan API call and then have all<br>
the relevant information. Our<br>
debugger team would really like to have the same functionality<br>
available for live processes and<br>
core dumps, since that is a better user experience.<br>
<br>
In the following weeks, we'll be submitting patches to reify some of<br>
the information available in<br>
the API and error reports. Please comment on information you'd like to<br>
see reified too.<br>
<br>
Thank you,<br>
<br>
  Filipe<br>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</blockquote></div><br></div></div></div>