On 03/09/2012 05:10 AM, [email protected] wrote: > Hi, > > I've tried to lunch KGDB on Qualcomm's platform MSM-8255 and after few days > finally succeeded. > Because of the fact that platform is based on two ARM processors (radio/modem > based on ARM9 and Linux/apps based on ARM11) I needed to provide a few > modifications on the Linux side to secure modem MCU while suspending Linux on > the breakpoint. > In particular it was necessary to handle modem watchdog while hanging on > breakpoint to avoid resetting the platform. > What I wanted to achieve was suspending the modem watchdog when entering > breakpoint and resuming it when leaving breakpoint. For that I have extended > the architecture specific part of KGDB for two new hooks which are intended > to be set in arch/arm code. > > I think the arch code should have a chance to prepare for > breakpoint/exception and cleanup after it. >
There is probably no problem with your patch, but this patch cannot get merged until there is something that is also queued to use this API. Are there more patches in a series that are not posted to this list? > >>From 9b7ccd2b1508c4a4b2e8af90fa3510de21e02499 Mon Sep 17 00:00:00 2001 > From: Michal Frynas <[email protected]> > Date: Fri, 9 Mar 2012 11:29:11 +0100 > Subject: [PATCH] KGDB: arch specific pre_exception and post_exception hooks > > Structure kgdb_arch extends for two new architecture specific hooks: > pre_exception being invoked before hitting a breakpoint and > post_exception called just after leaving the breakpoint. You also want to include a "Signed-off-by" line per the kernel.org guide lines. See section 5.4: http://www.linuxfoundation.org/content/how-participate-linux-community-0 > --- a/kernel/debug/debug_core.c > +++ b/kernel/debug/debug_core.c > @@ -568,6 +568,10 @@ return_normal: > if (dbg_io_ops->pre_exception) > dbg_io_ops->pre_exception(); > > + /* Call architecture specific pre_exception routine */ > + if (arch_kgdb_ops.pre_exception) > + arch_kgdb_ops.pre_exception(); > + > /* > * Get the passive CPU lock which will hold all the non-primary > * CPU in a spin state while the debugger is active > @@ -624,6 +628,10 @@ cpu_master_loop: > } > } > > + /* Call architecture specific post_exception routine */ > + if (arch_kgdb_ops.post_exception) > + arch_kgdb_ops.post_exception(); > + Depending on what kind of code you have there for cleaning up the exception this block might need to be moved further toward the end or you might need an additional callback to institute a restart of the kernel execution. I am assuming there was something special you had to do in terms of an IPI or something to make the co-processor or other cpu sync and stop. There might be other considerations you need in order to debug the state of the other cpu or co-processor in the future via kdb or the info-threads in gdb, depending on how the device is actually structured. Cheers, Jason. ------------------------------------------------------------------------------ This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure _______________________________________________ Kgdb-bugreport mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/kgdb-bugreport
