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: Juha Lumme <juha dot lumme at gmail dot com>
- To: Petr Hluzín <petr dot hluzin at gmail dot com>
- Cc: gdb <gdb at sourceware dot org>
- Date: Tue, 24 Sep 2013 10:40:16 +0900
- 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>
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.
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...
On Sat, Sep 21, 2013 at 10:39 PM, Petr Hluzín <firstname.lastname@example.org> wrote:
> (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@example.com> 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
>> 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
> Petr Hluzin