----- Original Message -----
On Wed, Mar 20, 2013 at 10:56 PM, Dave Anderson
<anderson(a)redhat.com>
wrote:
>
>
> ----- Original Message -----
>
>> >
>> > On that note, I only have a handful of sample ARM vmcore
>> > dumpfiles,
>> > and none of their kernels have any modules. My supposition was
>> > that
>> > it is simply common usage that ARM kernels are built without
>> > modules
>> > because of their typically embedded use-cases.
>> >
>> > In any case, if somebody can make a sample ARM vmcore available
>> > to
>> > me that does have modules, I'd appreciate having it on hand for
>> > testing.
>> >
>>
>> Here is one such dump file:
http://sdrv.ms/ZTjmUn
>> For I don't want anyone to access it, I don't post towards the
>> maillist.
>>
>> Thanks,
>> Lei
>>
>
> Got them -- thanks!
>
> I note that when running with an x86_64 binary that I built
> using "make target=ARM", that I don't see data or bss symbols
> either before or after loading the modules. I did this:
So what it means?...
Kernel build method is wrong?
I don't understand why module would be showed in the "before" file,
shouldn't it only existed in "after" file for module being loaded?
Should I do anything else to check?...
Thanks,
Lei
With respect to "mod -[sS]", it seems to be a problem that can be partially
addressed by doing this:
--- crash/symbols.c 2013-03-21 10:00:10.173201102 -0400
+++ ARM_crash-6.1.4/symbols.c 2013-03-21 10:06:01.531186455 -0400
@@ -10560,7 +10560,7 @@
break;
}
}
- if (i < lm->mod_sections) {
+ if (i <= lm->mod_sections) {
if (CRASHDEBUG(2))
fprintf(fp, "%08lx (%c) [%s] %s\n",
(ulong)syminfo.value,
And then it would also require filtering out the symbols types, because doing
the above also captures (U) and (a) types.
But it's ARM-specific, though, because the patch above causes problems with
x86_64.
Dave