This is the mail archive of the gdb@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Using gdb to debug FIQ on arm9 (imx233), and running into "Cannot find bounds of current function"


Hi Juha

Dne 24.9.2013 1:40 "Juha Lumme" <juha.lumme@gmail.com> 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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]