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

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

[Sorry for delay, I was OOO. ]
+kuba, who did something related in the past. (
http://llvm.org/viewvc/llvm-project?view=revision&revision=218538)

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> 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
> 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/1f61e4dd/attachment.html>

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