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

Quoting Steven Rostedt (2021-03-03 17:19:32)

On Wed, 03 Mar 2021 16:38:28 -0800
Stephen Boyd [off-list ref] wrote:

quoted

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.

quoted

│ 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.

quoted

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).

quoted

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.