Dave Anderson wrote: > ----- "Michael Holzheu" <holzheu@xxxxxxxxxxxxxxxxxx> wrote: > >>> So there would be that restriction as to the *relative* locations of >>> the .ko and .ko.debug files. But I don't think that's really all that >>> burdensome. >>> >>> Comments? >> I think that's a good proposal! >> >> Michael > > OK, so here's the proposal: > > - Make the currently-existing "mod -S <release-dir>" command find both the > stripped "<module>.ko" and its associated "<module.ko.debug>" > > Prerequisite: > > - Both the "<module>.ko" and "<module.ko.debug>" files must be located in > or under the <release-dir>. > > The search mechanism for the stripped "<module>.ko" file would be: > > - Search the complete <release-dir> tree for "<module>.ko". > . When found, save the relative directory pathname containing the file, > where the <relative-dir-path> would be rooted from <release-dir>. > > The search mechanism for the associated "<module>.ko.debug" file would be > done in this order: > > 1. Search the <release-dir>/<relative-dir-path> directory > 2. Search the <release-dir>/<relative-dir-path>/.debug directory > 3. Search the <release-dir>/usr/lib/debug/<relative-dir-path> directory > > This scheme would allow an alternate module/module-debuginfo setup to > be done like so: > > $ mkdir <release-dir> > $ cd <release-dir> > $ rpm2cpio kernel-<release>.rpm | cpio -idv > $ rpm2cpio kernel-debuginfo-<release>.rpm | cpio -idv > > And then the modules and their debuginfo data could be loaded using > the current alternative mechanism: > > crash> mod -S <release-dir> > > Also, because of the 1-2-3 debuginfo search order above, this would allow > the copying of "<module>.ko" and "<module>.ko.debug" files into the same > directory anywhere underneath <target-dir>, or in the ".debug" subdirectory > of the directory containing "<module>.ko". > > That being the case, it would be easy to handle per-release oddities such > as the RHEL /lib/modules/<release>/updates directory, by simply copying the > associated <module>.ko.debug file into the same directory as its stripped file. > > Guy -- are you on board with this? This looks good to me. In our automated setup environment we always create a script in the same dir as the vmcore that will start crash with the right vmcore and vmlinux filenames on the commandline. It would be really cool if we could specify the module search prefix there as well, so "mod -S" would "just work". Being able to use "mod -S ." is enough, though. --Guy -- Crash-utility mailing list Crash-utility@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/crash-utility
