Re: [PATCH 5/7] printk: Make %pS and friends print module build ID

[Stephen Boyd]

Quoting Steven Rostedt (2021-03-03 17:19:32)
> On Wed, 03 Mar 2021 16:38:28 -0800
> Stephen Boyd <swboyd@xxxxxxxxxxxx> wrote:
> 
> > I'm starting to feel like nobody read the commit text, or I messed up
> > somehow and the commit text was confusing? :(
> > 
> 
> I read it, I'm just unfamiliar with it. I don't use pstore, and I'm not
> sure what "crashdump" is. Do you mean the kexec/kdump? in which case
> you can retrieve data within the kernel quite easily.

Right, I meant kexec/kdump. Given that it is easy to retrieve it in
kdump (presumably with some scripting?) I can remove this motivation
from the commit text.

> 
> I haven't used debuginfod (never heard of it before actually).

Got it. Hopefully the links I provided were good enough? I will provide
a link next time.

> 
> > │ This is especially helpful for crash debugging with pstore or crashdump                                                                                                                                         
> > │ kernels. If we have the build ID for the module in the stacktrace we can                                                                                                                                        
> > │ request the debug symbols for the module from a remote debuginfod server                                                                                                                                        
> > │ or parse stacktraces at a later time with decode_stacktrace.sh by                                                                                                                                               
> > │ downloading the correct symbols based on the build ID. This cuts down on                                                                                                                                        
> > │ the amount of time and effort needed to find the correct kernel modules                                                                                                                                         
> > │ for a stacktrace by encoding that information into it.  
> 
> Are you saying it's common to have modules from different builds?

No.

> 
> > 
> > In some distro (read: non-kernel dev) workflows the vmlinux isn't
> > shipped on the device and crash handling is done offline or much later.
> > Using the build ID[1] is a common way to identify the binary that's
> > running on the device. In conjunction with a debuginfod[2] server you
> > can download the symbols for a crash automatically if you have the build
> > ID information.
> > 
> > I can add a patch that updates decode_stacktrace.sh to show how it can
> > download the correct vmlinux/modules if it isn't provided on the
> > commandline.
> 
> Are you just trying to match modules with the builds that they were
> created with?

Not exactly. I don't have a mapping of modules to the kernel they're
built/used with. I could create a mapping, but then that's something
else to maintain vs. what I have right now which is just a big database
of debuginfo mapped to build IDs (i.e. a debuginfod server).

> 
> > 
> > If the debug symbols are on some public server then in theory we could
> > have some robot sitting on the mailing list that looks for stacktraces
> > and automatically replies with information about the line number/file
> > and even provides the code snippet for the code that's crashing from
> > that binary, because it's all stored in the full debuginfo builds.
> 
> Again, I have no idea how buildids are created or what they are used
> for. This is the first time I've even heard about them. I'm all for
> helping other people out to make their workflow easier, if it doesn't
> make a mess for everyone else.
> 
> 

Makes sense and sounds good. Thanks.