[lldb-dev] [LLVMdev] Proposal: ASan debugging API

[Chandler Carruth]

Should probably involve the LLDB developers as well here.


On Wed, Jul 9, 2014 at 6:13 PM, Kuba Břečka <kuba.brecka at gmail.com> wrote:

> Hi,
>
> I would like to improve the debugging experience for ASan. The idea is to
> have a couple of useful commands in LLDB (probably implemented as Python
> scripts) that could help the user when they are debugging an ASan-enabled
> binary. We already have some debugging API (asan_interface.h):
>
>     // Print the description of addr (useful when debugging in gdb).
>     void __asan_describe_address(void *addr);
>
> What I'd like to have is a few more API on the ASan/compiler-rt side to
> query various information that ASan can provide, both about an error report
> and about general addresses, something like:
>
>     // Useful for calling from a debugger to get information about an
> error.
>     // If an error has been (or is beign) reported, returns the pc, bp, sp,
>     // address, access type, access type and bug description, and the
> return
>     // value of the function is 1. If no error occurred yet, returns 0.
>     int __asan_get_report_data(void **pc, void **bp, void **sp, void
> **addr,
>                                int *is_write, size_t *access_size,
>                                char **bug_description);
>
>     // Address/memory type from ASan's point of view.
>     typedef enum {
>       __ADDRESS_TYPE_UNKNOWN,
>       __ADDRESS_TYPE_SHADOW_LOW,
>       __ADDRESS_TYPE_SHADOW_GAP,
>       __ADDRESS_TYPE_SHADOW_HIGH,
>       __ADDRESS_TYPE_GLOBAL,
>       __ADDRESS_TYPE_STACK,
>       __ADDRESS_TYPE_HEAP,
>     } asan_address_type;
>
>     // Useful for calling from the debugger to get information about a
> pointer.
>     // Return one of the __ADDRESS_TYPE_* enum values. If global or stack,
> tries
>     // to also return the variable name, address and size. If heap, tries
> to
>     // return the chunk address and size.
>     int __asan_get_address_type(void *addr, char **region_name,
>                                 void **region_address, size_t
> *region_size);
>
>     // Useful for calling from the debugger to get the allocation stack
> trace
>     // and thread ID for a heap address. Returns 1 on success, 0 on error.
>     int __asan_get_alloc_stack(void *addr, void **trace, size_t
> *frame_count,
>                                void **top_frame_bp, int *thread_id);
>
>     // Useful for calling from the debugger to get the free stack trace
>     // and thread ID for a heap address. Returns 1 on success, 0 on error.
>     int __asan_get_free_stack(void *addr, void **trace, size_t
> *frame_count,
>                               void **top_frame_bp, int *thread_id);
>
>     // Useful for calling from the debugger to get the current shadow
> memory
>     // mapping.
>     void __asan_get_shadow_mapping(size_t *shadow_scale, size_t
> *shadow_offset);
> Hi,
>
> I would like to improve the debugging experience for ASan. The idea is to
> have a couple of useful commands in LLDB (probably implemented as Python
> scripts) that could help the user when they are debugging an ASan-enabled
> binary. We already have some debugging API (asan_interface.h):
>
>     // Print the description of addr (useful when debugging in gdb).
>     void __asan_describe_address(void *addr);
>
> What I'd like to have is a few more API to query various information that
> ASan can provide, both about an error report and about general addresses,
> something like:
>
>     // Useful for calling from a debugger to get information about an
> error.
>     // If an error has been (or is being) reported, returns the pc, bp, sp,
>     // address, access type, access type and bug description, and the
> return
>     // value of the function is 1. If no error occurred yet, returns 0.
>     int __asan_get_report_data(void **pc, void **bp, void **sp, void
> **addr,
>                                int *is_write, size_t *access_size,
>                                char **bug_description);
>
>     // Address/memory type from ASan's point of view.
>     typedef enum {
>       __ADDRESS_TYPE_UNKNOWN,
>       __ADDRESS_TYPE_SHADOW_LOW,
>       __ADDRESS_TYPE_SHADOW_GAP,
>       __ADDRESS_TYPE_SHADOW_HIGH,
>       __ADDRESS_TYPE_GLOBAL,
>       __ADDRESS_TYPE_STACK,
>       __ADDRESS_TYPE_HEAP,
>     } asan_address_type;
>
>     // Useful for calling from the debugger to get information about a
> pointer.
>     // Return one of the __ADDRESS_TYPE_* enum values. If global or stack,
> tries
>     // to also return the variable name, address and size. If heap, tries
> to
>     // return the chunk address and size.
>     int __asan_get_address_type(void *addr, char **region_name,
>                                 void **region_address, size_t
> *region_size);
>
>     // Useful for calling from the debugger to get the allocation stack
> trace
>     // and thread ID for a heap address. Returns 1 on success, 0 on error.
>     int __asan_get_alloc_stack(void *addr, void **trace, size_t
> *frame_count,
>                                void **top_frame_bp, int *thread_id);
>
>     // Useful for calling from the debugger to get the free stack trace
>     // and thread ID for a heap address. Returns 1 on success, 0 on error.
>     int __asan_get_free_stack(void *addr, void **trace, size_t
> *frame_count,
>                               void **top_frame_bp, int *thread_id);
>
>     // Useful for calling from the debugger to get the current shadow
> memory
>     // mapping.
>     void __asan_get_shadow_mapping(size_t *shadow_scale, size_t
> *shadow_offset);
>
> The information that this API would provide is currently only available in
> the textual form in ASan reports. Having an API to provide it would enable
> implementation of various tools/script for LLDB and GDB.
>
> Kuba
>
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20140709/27f4160b/attachment.html>