This is the mail archive of the
mailing list for the GDB project.
Re: Using gdb to debug FIQ on arm9 (imx233), and running into "Cannot find bounds of current function"
- From: Petr HluzÃn <petr dot hluzin at gmail dot com>
- To: Juha Lumme <juha dot lumme at gmail dot com>
- Cc: gdb <gdb at sourceware dot org>
- Date: Wed, 25 Sep 2013 00:57:20 +0200
- Subject: Re: Using gdb to debug FIQ on arm9 (imx233), and running into "Cannot find bounds of current function"
- Authentication-results: sourceware.org; auth=none
- References: <CAF-Ht3yHQOf4h9=5aqupCHiTm5ch6DCvufty+Z51TxSbdq8+Vw at mail dot gmail dot com> <CAC=yr6D9_M0kzk-Ho4S1mgYn0vXjmj80SwOCmeLaHsR31cWUVg at mail dot gmail dot com> <CAF-Ht3xU++4J4z034CV56za6ezrMKhEJ-JO3cjVMGwbMNoPyKg at mail dot gmail dot com>
Dne 24.9.2013 1:40 "Juha Lumme" <firstname.lastname@example.org> 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
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
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.