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(a)redhat.com [mailto:crash-utility-bounces@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