Re: mod -S and debuginfo kernel rpm

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



----- "Michael Holzheu" <holzheu@xxxxxxxxxxxxxxxxxx> 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

--
Crash-utility mailing list
Crash-utility@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/crash-utility

[Index of Archives]     [Fedora Development]     [Fedora Desktop]     [Fedora SELinux]     [Yosemite News]     [KDE Users]     [Fedora Tools]

 

Powered by Linux