[Crash-utility] modules and data / bss initialization

Castor Fu castor.fu at 3pardata.com
Mon Nov 20 22:26:39 UTC 2006


Yup -- it's easy enough to work around when one knows
what one wants, but it's kind of painful.  I have no idea why people
removed all this functionality from insmod.  I suppose someone wants
to hide more info?
 
If nobody else has fixed this I'll either do it myself or get someone else to do it in
the next week or so.
 
 
-----Original Message-----
From: crash-utility-bounces at redhat.com [mailto:crash-utility-bounces at redhat.com]On Behalf Of Dave Anderson
Sent: Monday, November 20, 2006 2:04 PM
To: Discussion list for crash utility usage, maintenance and development
Subject: Re: [Crash-utility] modules and data / bss initialization



Castor Fu wrote: 

  

Under linux 2.6 it seems that crash is not figuring out the locations 
of any sections of modules other than the text section. 


This means that things like 'sym modvar1' can find the correct location 
but 'p modvar1' does not work. 


I guess that there are a couple of possibilities here: 


1.  if CONFIG_KALLSYMS is set, one could look through the sect_attrs 
     for each of the sections and initialize the segments. 


2.  if CONFIG_KALLSYMS is not set, we would have to try to match 
       offsets of some variables from the object file with the existing offsets 
       in the kernel. 


Clearly [2]  is the 'better' solution because it doesn't 
      require CONFIG_KALLSYMS to be set, but it seems like more work. 


Has anyone done either of these yet?   If not does it seem like I've described the 
problem correctly? 


    Thanks, 
    castor

It's been years since that code has been tinkered with, 
and since I don't debug much module code, I wasn't even 
aware that there was a 2.6-only difference.  I thought that 
the add-symbol-file operation would properly assign the 
module's msymbols with the correct addresses for data 
symbols, which it does do correctly for the text symbols. 
(I think that's the issue with the "p" command, i.e., the 
embedded gdb is still using the offset value from 
the object file and failing...) 

Anyway, you can still do a "whatis modvar1", get the data type, 
and then either do a "struct" command with the address, or 
come up with a cobbled-together gdb print command, right? 


Dave 
  

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/crash-utility/attachments/20061120/6b6456c8/attachment.htm>


More information about the Crash-utility mailing list