This should be on a Wiki page if it's not already... Haven't had time to look.
On your build host, you would start gdb on your image.
On my machine, I do this as:
% gdb
(gdb) build_dir/linux-x86_alix2/linux-3.2.2
and I open the kernel:
(gdb) file vmlinux
then I look at the contents of /proc/modules on my target (# cat
/proc/modules), example:
...
cs5535_mfgpt 2054 2 geodewdt,cs5535_clockevt,[permanent], Live 0xd0df7000
cs5535_mfd 1548 0 - Live 0xd0ded000
mfd_core 1616 1 cs5535_mfd, Live 0xd0de3000
...
unfortunately, we don't have "modinfo" on the target, or you could just do:
# modinfo mfd_core | awk '/^filename:/ { print $2; }'
to get the paths to the modules... But it's not that hard to divine them.
Remembering that _ in a module name is usually - in a filename, I get:
drivers/mfd/mfd-core.ko
as the path of the 3rd module. I then do:
(gdb) add-symbol-file drivers/mfd/mfd-core.o 0xd0de3000
add symbol table from file "drivers/mfd/mfd-core.o" at
.text_addr = 0xd0de3000
(y or n) y
Reading symbols from
/home/philipp/openwrt-alix/build_dir/linux-x86_alix2/linux-3.2.2/drivers/mfd/mfd-core.o...(no
debugging symbols found)...done.
(gdb) directory drivers/mfd
to add the module's symbols (note the use of the .o file and not the .ko!), and
to put the directory containing the sources into the search path.
And if I had a crash at 0xd0de32b2, I can do:
(gdb) list *(0xd0de32b2)
0xd0de32b2 is in mfd_remove_devices (drivers/mfd/mfd-core.c:202).
197
198 void mfd_remove_devices(struct device *parent)
199 {
200 atomic_t *cnts = NULL;
201
202 device_for_each_child(parent, &cnts, mfd_remove_devices_fn);
203 kfree(cnts);
204 }
205 EXPORT_SYMBOL(mfd_remove_devices);
206
and I get the line the crash was at. Hopefully this helps.
It would be neat to have a script that one could paste /proc/modules into and a
stack trace that did this for us...
On 3/2/12 7:25 AM, Adam Gensler wrote:
> Went up to kernel version 3.2.5, problem still occurs. Above 3.2.5
> requires refreshing the kernel patches.
>
>
> On 2/29/12 11:18 PM, Adam Gensler wrote:
>> For what its worth I spent some time this evening putting together a
>> Fedora Core 16 virtual machine to test with. I pulled a fresh copy of
>> trunk and built the alix2 target and got the same traces on boot up.
>>
>> At this point I'm sure the issue isn't with my build environment but is
>> an issue in trunk. Unfortunately my kernel-debugging-foo isn't strong
>> enough to move closer to resolution.
>>
>>
>> On 2/28/12 7:09 PM, Adam Gensler wrote:
>>> Nothing I'm finding online seems to indicate a simple procedure for
>>> this. Perhaps I'm not searching for the correct terminology. If you have
>>> a sample / example I'd certainly take a look at doing it.
>>>
>>>
>>> On 2/28/12 5:12 PM, Philip Prindeville wrote:
>>>> As it turns out you only need 2-3 commands... you can almost script it
>>>> with macros.
>>>>
>>>>
>>>> On 2/28/12 2:17 PM, Adam Gensler wrote:
>>>>> Unfortunately I have zero experience with gdb. It would probably take
>>>>> longer to learn how to use that than to refresh to the kernel
>>>>> patches on
>>>>> 3.2 to support 3.2.7 so I could try that version to see if its already
>>>>> fixed.
_______________________________________________
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
