Re: PPC KGDB changes and some help?

[Amit S. Kale]

Hi,

Here it is: ppc kgdb from timesys kernel is available at
http://kgdb.sourceforge.net/kgdb-2/linux-2.6.1-kgdb-2.1.0.tar.bz2

This is my attempt at extracting kgdb from TimeSys kernel. It works well in 
TimeSys kernel, so blame me if above patch doesn't work.

ChangeLog:
2004-01-21 TimeSys Corporation
	* kgdb on powerpc.

2004-01-21 Pavel Machek <pavel@xxxxxxx>
	* Changes for coding conventions

2004-01-21 Tom Rini <trini@xxxxxxxxxxxxxxxxxxx>
	* Added a prototype for kgdb8250_add_port.


On Wednesday 21 Jan 2004 9:00 pm, Tom Rini wrote:
> 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.

-- 
Amit Kale
EmSysSoft (http://www.emsyssoft.com)
KGDB: Linux Kernel Source Level Debugger (http://kgdb.sourceforge.net)

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/