Re: [Crash-utility] mod -S and debuginfo kernel rpm
----- "Michael Holzheu" <holzheu(a)linux.vnet.ibm.com> wrote:
I thought that you where suggesting to search only in
<-S dir>/lib/modules.. and <-S dir>/usr/lib/debug/..
As I said before, "mod -S <dir>" currently searches in all
subdirectories of <dir>.
Right, that's what my follow-up email explained more thoroughly:
And just to clarify this further. When "mod -S
[directory]" is entered,
the search will be made starting from [directory]. In other words,
it will not immediately append "/lib/modules" and
"/usr/lib/debug/lib/modules"
onto [directory]. It's just that that's where they'll be found
if the double-rpm2cpio were done.
Conceivably you could just dump all the .ko and .ko.debug files into
the one flat [directory], and it will find them right away.
But that leads to another issue.
Suppose a directory target was set up with double-rpm2cpio, such that,
for example, the ext3.ko module would be found here:
<target-dir>/lib/modules/2.6.18-128.el5/kernel/fs/ext3/ext3.ko
The gdb algorithm currently searches for ext3.ko.debug in these 3
directories, in this order:
A. <target-dir>/lib/modules/2.6.18-128.el5/kernel/fs/ext3
B. <target-dir>/lib/modules/2.6.18-128.el5/kernel/fs/ext3/.debug
C. /usr/lib/debug/lib/modules/2.6.18-128.el5/kernel/fs/ext3
So it doesn't find it in the "double-rpm2cpio" layout. And so my
proposal would add this additional search path:
D. <target-dir>/usr/lib/debug/lib/modules/2.6.18-128.el5/kernel/fs/ext3
and it would find it. It's essentially "C", but with <target-dir>
prepended to the search path.
But it *does* require an analogous relative file tree layout.
So if for example, all .ko and .ko.debug files were just dumped in
the <target-dir>:
(1) ext3.ko would be found in <target-dir>
(2) ext3.ko.debug would be found in <target-dir> -- using gdb algorithm
"A".
But if ext3.ko was located in:
<target-dir>/lib/modules/2.6.18-128.el5/kernel/fs/ext3
then the proposed "D" algorithm would find ext3.ko.debug in:
<target-dir>/usr/lib/debug/lib/modules/2.6.18-128.el5/kernel/fs/ext3
But it would *only* find it in the directory above. And that's because
the gdb algorithms create fully-qualified directory pathnames based
upon the full path to the stripped .ko file, and then looks in those
directories to accomplish "A", "B" and "C".
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?
Dave