Sorry, cut and paste error. The first gdb command should have read:
(gdb) cd build_dir/linux-x86_alix2/linux-3.2.2
On 3/2/12 12:26 PM, Philip Prindeville wrote:
> 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
