Thanks for the tip on backtrace. Very handy Is it common to have so many stacks frames to have 0x00000000 as the address? That seems a bit odd to me.
x0026b02c -- 0x0016f878 + 0xfb7b4 _end 0x00000000 -- unknown address 0x00000000 -- unknown address 0x00000000 -- unknown address 0x00000003 -- unknown address 0x00000000 -- unknown address 0x00000007 -- unknown address 0x00155000 -- 0x00155000 + 0x0000 set_reset_devices 0x00155000 -- 0x00155000 + 0x0000 set_reset_devices 0x00155000 -- 0x00155000 + 0x0000 set_reset_devices 0x00000000 -- unknown address 0x00000000 -- unknown address 0x00000000 -- unknown address 0x00000000 -- unknown address 0x00000000 -- unknown address 0x00000000 -- unknown address 0x00000000 -- unknown address 0x00000000 -- unknown address 0x00000000 -- unknown address 0x00000000 -- unknown address 0x00000000 -- unknown address 0x00000000 -- unknown address 0x00000000 -- unknown address 0x00000000 -- unknown address 0x00000000 -- unknown address 0x00000000 -- unknown address 0x00000000 -- unknown address 0x00000000 -- unknown address 0x00000000 -- unknown address 0x00000000 -- unknown address 0x00000000 -- unknown address 0x00000000 -- unknown address 0x00000000 -- unknown address 0x00000000 -- unknown address 0x00000000 -- unknown address 0x00000000 -- unknown address 0x00000000 -- unknown address 0x00000000 -- unknown address 0x00000000 -- unknown address 0x0026b160 -- 0x0016f878 + 0xfb8e8 _end On Mar 2, 2010, at 6:38 AM, Stern, Allon wrote: > > On Mar 2, 2010, at 12:02 AM, Greg Hulands wrote: > >> I tried to enable the Full Symbolic/Source Debugging support option in the >> kernel hacking section, but no new info was displayed in the crash. Is this >> only if I connect via gdb to get the symbolic stack? > >> I would actually like to work out why the normal init isn't working >> properly. Is someone able to give me the gist of what to do to track it down? > > One think you can look at, if you can't get symbolic traces, is look at the > System.map file which is generated along with your kernel. It shows you the > starting address for each function in the kernel. > > There is a handy perl script here: ftp://ftp.denx.de/pub/tools/backtrace > > which will take a System.map file, then reads standard input - you can paste > your backtrace into stdin, and it will look up the symbols for those > addresses and give it to you in a more human-readable fashion, with function > names and offsets. > > You can also take your kernel, run it through m68k-uclinux-objdump -S to get > a full disassembly of the kernel (redirect the output to a file). Then peruse > the file, and look for the offset where your failure occurred. > > Good luck! > - > allon > > > ------------------------------------------------------------------------------------------ > Disclaimer > The information contained in this email is intended solely for the > use of the individual(s) to whom it is addressed. It may contain > proprietary, privileged or other sensitive data. If you believe you > have received this email in error, please do not share this email > with anyone but instead notify the sender immediately. In addition, > please delete this email and any attachments from your computer. > > _______________________________________________ > uClinux-dev mailing list > uClinux-dev@uclinux.org > http://mailman.uclinux.org/mailman/listinfo/uclinux-dev > This message was resent by uclinux-dev@uclinux.org > To unsubscribe see: > http://mailman.uclinux.org/mailman/options/uclinux-dev _______________________________________________ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
