From mboxrd@z Thu Jan 1 00:00:00 1970 Date: Wed, 21 Jan 2004 08:30:19 -0700 From: Tom Rini To: "Amit S. Kale" Cc: Powerpc Linux Subject: Re: PPC KGDB changes and some help? Message-ID: <20040121153019.GR13454@stop.crashing.org> References: <20040120172708.GN13454@stop.crashing.org> <200401211946.17969.amitkale@emsyssoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii In-Reply-To: <200401211946.17969.amitkale@emsyssoft.com> Sender: owner-linuxppc-dev@lists.linuxppc.org List-Id: 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/