[llvm-dev] [RFC] ASan: Reify all information relevant for diagnostics
Kostya Serebryany via llvm-dev
llvm-dev at lists.llvm.org
Thu Jul 14 14:32:54 PDT 2016
[Sorry for delay, I was OOO. ]
+kuba, who did something related in the past. (
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.
* 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.
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
> 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
> 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,
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the llvm-dev