Re: PPC KGDB changes and some help?

[Tom Rini <trini@kernel.crashing.org>]

On Wed, Jan 21, 2004 at 07:46:17PM +0530, Amit S. Kale wrote:

> Hi Tom,
>
> Yes. Software breakpoints have been tested in the TimeSys ppc kernel source.
> They work quite well!! I'll be releasing that code soon.

Any chance you can give me what they gave you?  I can try and merge
and test things.

> Here are a couple of questions from a quick look at this code. I may have more
> when I do a merge this code with what I have.
>
> > -	bl	schedule
> > +	bl	user_schedule
>
> I still have #ifdef CONFIG_KGDB_THREAD here. Threads listing is a necessary
> feature, agreed. Do you have any ideas on reducing the overhead of the code
> added by having to push all registers when doing a switch_to?
>
> if (kgdb enabled) do a full push of registers else go to usual switch_to
>
> Does this sound good?

>From what I recall of starting on this around kgdb 2.0.2, I couldn't
link the kernel w/o this change (KGDB=n).

> > +        */
> > +#if 0
> > +       extern atomic_t kgdb_setting_breakpoint;
> > +       if (atomic_read(&kgdb_setting_breakpoint))
> > +               regs->nip += 4;
> > +#else
> > +       if (linux_regs->nip == 0x7d821008 )
> > +               /* Skip over breakpoint trap insn */
> > +               linux_regs->nip += 4;
> > +#endif
>
> Why is kgdb_setting_breakpoint a bad idea?
> My guess - problems on an smp board.

I don't know how well the current kgdb stub is tested on SMP, but it
doesn't need any extra locking here.

> Hardcoded nip is worse.
> Any ideas for a better code?

I've got a feeling that the nip is always the trap instruction, so we
could always do what the TimeSys code (and before that, the current
stub) does of skipping over it.  I used the hard-coded value there since
I hadn't gotten around to re-arranging the code so I could do *(uint
*)kgdb_ops->gdb_bpt_instr or so.

> In following code, gdb packets and their responses appear correct. kgdb is
> supposed handle software breakpoints.
>
> The breakpoint 0xc0000000 placed by gdb is _evil_ It may clobber data. The gdb
> at kgdb.sourceforge.net places it correctly at module_event.

I'm not quite sure what you're getting at.   The gdb binary I'm using is
a good one (It's happy w/ the current kgdb stub, working in tandem w/ a
BDI2000, etc).  If the breakpoints being set aren't right, I suspect
that it's related to the other problems I'm seeing.

> Where is the other breakpoint placed? While you would have certainly done
> that, please confirm that kgdb actually inserts a breakpoint where you have
> asked it to: a simple printk at the address where the breakpoint is placed
> should be sufficient. printing from gdb will not work as gdb removes all
> breakpoints before giving control to a user.

The thing is the kernel gets into an infinite loop of stopping, as far
as gdb can tell, at the initial breakpoint.

--
Tom Rini
http://gate.crashing.org/~trini/

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/