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=yr6D9_M0kzk-Ho4S1mgYn0vXjmj80SwOCmeLaHsR31cWUVg@mail.gmail.com> |
Hi (The regulars did not reply, at least you'll get a low quality reply from me.) On 17 September 2013 16:09, Juha Lumme <[email protected]> wrote: > ... > Now I continue executing the code, and initiate the condition to > trigger the FIQ, the gdb properly breaks: > Breakpoint 1, 0xffff001c in ?? () This line means that GDB does not know what function is being executed. This is because set_fiq_handler() copies your FIQ routine at the end of interrupt table - I personally would expect to take address of your interrupt routine and write a mere jump to it, however I am not familiar with ARM. Making GDB work in this situation would be difficult, I guess you could abuse GDB's overlay support or use JIT debug symbol adding, clearly an overkill. Instead I recommend to use set_fiq_handler() to copy a single absolute-jump instruction that would execute your FIQ routine. > > If I try "stepi", the whole thing just locks up, and I can't do > anything anymore on that session.. I can't seem to move past this > after this, and not sure what to try next.. > Any ideas what I might be doing wrong ? I think "stepi" should work even in this situation. Does GDB hang by waiting on a remote target (openocd)? Anyway, the code of set_fiq_handler() does not check the `length' parameter. If I understand the meaning correctly then there is a (small) limit for the parameter and an assertion would be appropriate. (This seems to be related to http://stackoverflow.com/questions/18823285/gdb-arm-debugger-unable-to-trigger-into-fiq-in-linux-driver.) -- Petr Hluzin