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.

quoted

-	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).

quoted

+        */
+#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/