Hi Daniel, On Mon, Feb 27, 2023 at 07:34:56PM +0000, Daniel Müller wrote: > Symbolization of addresses is a commonly encountered problem, maybe most so in > the context of BPF and tracing with the capturing of stack traces. Perhaps > superficially straightforward-looking, there a variety of considerations and > intricacies, such as: > - different formats/standards (e.g., ELF symbol information, DWARF, GSYM) cater > to different use cases and require vastly different steps to work with > - on top of that, even if a library such as libelf or libdwarf is relied on, > plenty of format specific details need to be known to symbolize addresses > properly > - discovery of symbolization sources (e.g., DWARF debug files) > - symbolization trade-offs (performance, memory usage) > - system-specific details and corner cases > > We are working on blazesym [0], a library that aims to provide users with a > batteries-included experience for symbolizing addresses (but also the reverse: > mapping symbols to addresses). > > We would like to provide a brief overview of the library and its goals and then > open up for discussion. Some topics we are specifically interested in > understanding better: > - What are current issues with symbolization that would be great to support? > - Does the usage of Rust pose a problem in your context? (C bindings are > available, but a Rust toolchain is required for building; are pre-built > binaries and packages for common distributions sufficient for your use cases?) > > In general, we'd be interested in hearing your use cases and in discussing > whether blazesym is a fit or could be made to work. I didn't look super close at blazesym yet, but was wondering if it would support a use case I have in mind. Context is it's tricky to determine why a packet was dropped by kernel. kfree_skb_reason() with caller address in `location` is a good start but we can do better I think. The issue is the call stack alone is not enough detail. I want to see all the branches taken in the case a single call frame has multiple ways to drop. Vague idea is to use the recent LBR work (also haven't looked hard yet, so this may not be possible) to take LBR stack at `tracepoint:skb:kfree_skb` tracepoint. Then map the branches to line numbers. So my question is this: can/will blazesym be able to map kernel addresses to line numbers / file names? Thanks, Daniel
