[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

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,


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


[Sorry for delay, I was OOO. ]

+kuba, who did something related in the past. (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.