Hi list, I find in current 6.1.4 crash, when load module with "mod -S", only module's function symbol could be parsed out. But for module's global variant, crash cannot find related symbol... Any idea for this?

Dave, On Tue, Mar 19, 2013 at 10:31 PM, Dave Anderson <anderson(a)redhat.com&gt; wrote: > > > ----- Original Message ----- >> Hi list, >> >> I find in current 6.1.4 crash, when load module with "mod -S", >> only module's function symbol could be parsed out. >> >> But for module's global variant, crash cannot find related >> symbol... >> Any idea for this? >> > > Without the debuginfo data from the module.ko.debug file, crash > gets all of its module symbol data from the kernel. So it uses > what's available in the in-kernel /proc/kallsyms list plus the > information stored in each module's "struct module". The > store_module_symbols_v2() function does the work. > > If "mod -[sS]" is used, then crash has access to full debuginfo > data > from the module.ko.debug file. In that case, the > store_load_module_symbols() > function does the work. > For current, what I saw is when I have loaded the module, only the t or T type symbol is installed, while others like d or D type it would not be loaded at all... While for one symbol, I already knows its member has a specific magic number, so that I search the memory, and find its virtual address becomes to 0xexxxxxxx, not the 0xbfxxxxxx. So does it mean the debuginfo in that module only has text related, while data type are all muted, and why?... Thanks, Lei

On Tue, Mar 19, 2013 at 10:58 PM, Dave Anderson <anderson(a)redhat.com&gt; wrote: > > > ----- Original Message ----- >> Dave, >> >> On Tue, Mar 19, 2013 at 10:31 PM, Dave Anderson >> <anderson(a)redhat.com&gt; >> wrote: >> > >> > >> > ----- Original Message ----- >> >> Hi list, >> >> >> >> I find in current 6.1.4 crash, when load module with "mod -S", >> >> only module's function symbol could be parsed out. >> >> >> >> But for module's global variant, crash cannot find related >> >> symbol... >> >> Any idea for this? >> >> >> > >> > Without the debuginfo data from the module.ko.debug file, crash >> > gets all of its module symbol data from the kernel. So it uses >> > what's available in the in-kernel /proc/kallsyms list plus the >> > information stored in each module's "struct module". The >> > store_module_symbols_v2() function does the work. >> > >> > If "mod -[sS]" is used, then crash has access to full debuginfo >> > data >> > from the module.ko.debug file. In that case, the >> > store_load_module_symbols() >> > function does the work. >> > >> >> For current, what I saw is when I have loaded the module, only >> the t or T type symbol is installed, while others like d or D type it >> would not be loaded at all... >> >> While for one symbol, I already knows its member has a specific >> magic number, so that I search the memory, and find its virtual >> address becomes to 0xexxxxxxx, not the 0xbfxxxxxx. >> So does it mean the debuginfo in that module only has text related, >> while data type are all muted, and why?... >> >> >> Thanks, >> Lei > > I have no idea. With x86/x86_64 you can see text, data and bss > symbols both before and after the "mod -[sS]" command is run. > > Dave > Add Mike... Mike, Do you have any idea for this? Thanks, Lei

I have one beagleboard vmcore which seems to have modules loaded but unfortunately I don't seem have the module .ko files anywhere around :-( I believe Per and Jan are using more recent kernel on their ARM devices with kdump enabled. Maybe they can provide more information on this?

On Wed, Mar 20, 2013 at 06:06:21PM +0800, Lei Wen wrote: > On Tue, Mar 19, 2013 at 10:58 PM, Dave Anderson <anderson(a)redhat.com&gt; wrote: > > > > > > ----- Original Message ----- > >> Dave, > >> > >> On Tue, Mar 19, 2013 at 10:31 PM, Dave Anderson <anderson(a)redhat.com&gt; > >> wrote: > >> > > >> > > >> > ----- Original Message ----- > >> >> Hi list, > >> >> > >> >> I find in current 6.1.4 crash, when load module with "mod -S", > >> >> only module's function symbol could be parsed out. > >> >> > >> >> But for module's global variant, crash cannot find related > >> >> symbol... > >> >> Any idea for this? > >> >> > >> > > >> > Without the debuginfo data from the module.ko.debug file, crash > >> > gets all of its module symbol data from the kernel. So it uses > >> > what's available in the in-kernel /proc/kallsyms list plus the > >> > information stored in each module's "struct module". The > >> > store_module_symbols_v2() function does the work. > >> > > >> > If "mod -[sS]" is used, then crash has access to full debuginfo > >> > data > >> > from the module.ko.debug file. In that case, the > >> > store_load_module_symbols() > >> > function does the work. > >> > > >> > >> For current, what I saw is when I have loaded the module, only > >> the t or T type symbol is installed, while others like d or D type it > >> would not be loaded at all... > >> > >> While for one symbol, I already knows its member has a specific > >> magic number, so that I search the memory, and find its virtual > >> address becomes to 0xexxxxxxx, not the 0xbfxxxxxx. > >> So does it mean the debuginfo in that module only has text related, > >> while data type are all muted, and why?... > >> > >> > >> Thanks, > >> Lei > > > > I have no idea. With x86/x86_64 you can see text, data and bss > > symbols both before and after the "mod -[sS]" command is run. > > > > Dave > > > > Add Mike... > > Mike, > Do you have any idea for this? My first question would be are you now using the normal kernel kdump or the custom one? The former is supported and used to work last time I tried. Back at Nokia we had N9 kernel which had a lot of modules.

I have one beagleboard vmcore which seems to have modules loaded but unfortunately I don't seem have the module .ko files anywhere around :-( I believe Per and Jan are using more recent kernel on their ARM devices with kdump enabled. Maybe they can provide more information on this?

On Thu, Mar 21, 2013 at 08:07:36AM +0800, Lei Wen wrote: > > My first question would be are you now using the normal kernel kdump or the > > custom one? The former is supported and used to work last time I tried. Back > > at Nokia we had N9 kernel which had a lot of modules. > > Yes, I don't use the kdump method, but very similar. > However could it explain why only module data could not be seen, while module > function is still there? ... Well, anything is possible :-) And last time it overwrote the kernel text... Are you able to try the standard kdump? Just to be sure that this problem happens with that as well.