[llvm-dev] [RFC] ASan: Reify all information relevant for diagnostics

[Anna Zaks via llvm-dev]

> On Jul 14, 2016, at 2:32 PM, Kostya Serebryany via llvm-dev <llvm-dev at lists.llvm.org> wrote:
> 
> [Sorry for delay, I was OOO. ]
> +kuba, who did something related in the past. (http://llvm.org/viewvc/llvm-project?view=revision&revision=218538 <http://llvm.org/viewvc/llvm-project?view=revision&revision=218538>)
> 

These APIs Kuba added for ASan and TSan are being used by lldb, so you can also take a look at how the debugger part is implemented. 

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160714/bea3fcb3/attachment.html>