dswei wrote: > Hello, all. > A program, before it can run at it's runtime address, it has to configure > the memory, copy itself to the memory, > or enable the MMU; after these, it can run at it's runtime address. > My question is, how can I debug it with OpenOCD and gdb, when it does not > run at it's runtime address? > This is a example, when I debug the linux kernel, the gdb command 'break' > can't work before the MMU > is enabled , the address of the break point does not exist yet. My method > is: telnet the OpenOCD, 'step' to > the instuction 'turn_on_mmu. Just after the MMU is enable, I can set the > break point use GDB. > But this method is difficult for newbie. > Do somebody have a easy way? > Yes, it is quite easy. Set a HARDWARE instruction break point at that address, and RUN.
Note the difference - I said an instruction hardware break point - not soft break point, and not read or write break point. Depending on your OS - it may need to *LOAD* the application into memory. Often a "write breakpoint" would happen application is loaded from FLASH, or from TFTP etc. Also note: Depending on your OS - if it supports "demand page virtual memory" (ones I have been involved with did) you often require an OS hack that forces the application to be resident in memory, otherwise GDB tries to set a break point on an non-resident memory location and faults. Yuck. BTW - this also lets you run & debug other operating systems like the linux kernel - that you TFTP boot because it takes too damn long to JTAG a 1MEG operating system image into memory. -Duane. _______________________________________________ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
