Re: [Crash-utility] mod -S and debuginfo kernel rpm
Dave Anderson wrote:
----- "Michael Holzheu" <holzheu(a)linux.vnet.ibm.com>
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