From mboxrd@z Thu Jan 1 00:00:00 1970 From: Brent Cook Date: Fri, 13 Oct 2006 13:52:21 -0500 Subject: [U-Boot-Users] debug u-boot using bdi2000 In-Reply-To: <1160765295.27646.105.camel@saruman.qstreams.net> References: <198592450610131041q33fc9160u3aa7afb2422e09fc@mail.gmail.com> <452FDD3A.1050004@freescale.com> <1160765295.27646.105.camel@saruman.qstreams.net> Message-ID: <200610131352.21742.bcook@bpointsys.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de On Friday 13 October 2006 13:48, Ben Warren wrote: > On Fri, 2006-10-13 at 13:38 -0500, Timur Tabi wrote: > > Ben Warren wrote: > > > I don't know how well supported your CPU is (I've never heard of it, > > > but that's not saying much) Anyway, I've debugged ROM on a couple of > > > different MPC8349s, but not with 100% success. I can single-step with > > > the BDI, and can single-step assembly code, but not C code using gdb. > > > > I don't know about PowerPC processors, but on x86, single-stepping > > assembly code is completely different from single-stepping C code. With > > assembly, the debugger typically enables instruction interrupts, where an > > interrupt is generated after each instruction is executed. This does not > > require modifying memory. > > > > With C code, a single line of C code is usually multiple assembly > > instructions, so the debugger (gdb in this case) places a breakpoint at > > the appropriate spot. > > That's some good insight, and would certainly explain my problem. > Thanks! > > Ben I find it really helpful when debugging C code in ROM to have the output of 'cross-compiler-objdump -d u-boot | less' handy for looking up functions and such. It's not too hard to get familiar with your CPU's ABI either, after a bit of this.