Hi Daniel, On Mon, Feb 27, 2023 at 02:41:15PM -0700, Daniel Xu wrote: > On Mon, Feb 27, 2023 at 09:34:30PM +0000, Daniel Müller wrote: > > On Mon, Feb 27, 2023 at 01:07:48PM -0700, Daniel Xu wrote: > > > So my question is this: can/will blazesym be able to map kernel > > > addresses to line numbers / file names? > > > > Blazesym should be able to help with the symbolization aspect, yes. That is, it > > can convert the addresses you captured into symbol name + source file + line > > information as you asked for (you may need DWARF debug information for anything > > beyond mere symbol names). In general, the library is able to handle both user > > space and kernel addresses. > > Awesome, sounds great. After looking slightly more carefully, how about > split debug info support and debuginfod support? Extremely unlikely > anybody ships production kernels with debug symbols. But debuginfod > service is more likely. Good questions. Split debug information is definitely something we want to support out of the box, but we still lack such support at this point (it's still somewhat early days). Regarding debuginfod, we had some discussions about it in the past and it is also something we are interested in supporting in some form. The way it will most likely work is that the library will provide an interface that accepts a callback that is invoked as part of the symbolization process and which allows the user to fetch debug info based on data such as the build ID of a binary (passed to the callback). So it will likely be up to the user to make an HTTP request to a debuginfod instance and fetch the data. Once that is done (and the callback returns) blazesym would take over again and use that debug information to complete the symbolization request. (We may provide a default implementation for such a callback that does all the heavy lifting; in the batteries-included spirit) Daniel
