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.
