Messages in this thread | | | From | "Amit S. Kale" <> | Subject | Re: PPC KGDB changes and some help? | Date | Wed, 21 Jan 2004 22:23:12 +0530 |
| |
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@suse.cz> * Changes for coding conventions
2004-01-21 Tom Rini <trini@kernel.crashing.org> * 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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |