On 04/01/14 03:22, Peter Maydell wrote:
On 1 April 2014 01:35, Michael Casadevall <michael.casadev...@linaro.org> wrote:
Its a fairly major improvement, and I managed to use GdbSyms.dll to
load ALL the symbol files in a single go, but I'm still having issues
with the stack. At least now i can get the frame we're currently in
reliably, but the backtrace remains busted.
Hrmm. If you ask gdb about native register values and the raw contents
of the stack, you might be able to figure out (in conjunction with the
disassembly of the relevant functions and the procedure calling
standard) whether the problem is QEMU reporting bogus register
values or if UEFI has been compiled with some funny options that
cause it not to put in stack frames, or something else.
Would this problem be a situation where Ftrace anor KernelShark + Ftrace
or KernelShark + trace-cmd would ease the pain of debugging?
If not, why?
curiously,
James
[1] http://elinux.org/Ftrace
[2] https://lwn.net/Articles/425583/
[3]
http://chemnitzer.linux-tage.de/2012/vortraege/shortpaper/985_Rostedt.txt
[4] http://rostedt.homelinux.com/kernelshark/
_______________________________________________
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
