Re: Using gdb to debug FIQ on arm9 (imx233), and running into "Cannot find bounds of current function"
Petr Hluzín <[email protected]>
| Newsgroups | gmane.comp.gdb.devel |
|---|---|
| Message-ID | <CAC=yr6DRNu_A12PVi23GW9mj1w-pdzRbVjiCq0g5bdJ_gnmMnw@mail.gmail.com> |
Hi Juha Dne 24.9.2013 1:40 "Juha Lumme" <[email protected]> napsal(a): > > Hi Petr, > > Thanks for your reply. Indeed the stackoverflow question is related to > this, it's mine after all ;) > I'm not really sure how would a jump instruction in the > set_fiq_handler help here, since this method only copies the FIQ code > to the designated area for FIQ, to be executed when FIQ is triggered. I am not suggesting to put a jump instruction into set_fiq_handler(), I am suggesting to create a dummy function (e.g. my_fiq_trampoline) that would contain a single instruction - an absolute jump to your real FIQ handler function (e.g. my_fiq_func). Then, instead of calling set_fiq_handler(&my_fiq_func), you would call set_fiq_handler(&my_fiq_trampoline). This way my_fiq_func() would lie where gdb expects it; line numbers, breakpoints, call stacks, etc. would work as usual. Because set_fiq_handler() copies instructions without telling gdb it does not what function is there (or even the memory contains instructions and not data). Of course this all is in vain if openocd cannot operate when FIQ is triggered. You can see if gdb is waiting on openocd by typing set remotelogfile protocol.txt. AFAIK debugging over a JTAG should work in any CPU state, however if openocd uses some support from some kind of monitor code then it would explain the hang. > > Yes, when I try "stepi" after FIQ has been triggered, GDB seems to > wait for openocd, or at least I think so, the GUI (ddd) keeps blinking > the green light, and nothing much happens after that. Though, I'm also > not too familiar with this yet. > > Currently I can somehow debug the handler by copying the FIQ code to > the driver, and added few instructions to set the processor in FIQ > mode, as suggested by the answer in SO. It was manageable, and I could > find the problem spots, but it is a bit tedious... > This indicates that openoced can debug with CPU in FIQ mode, maybe it cannot if the mode is entered in a different way. Maybe gdb waits for something completely different. -- Petr Hluzin