lkml.org 
[lkml]   [2004]   [Jan]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    SubjectRe: PPC KGDB changes and some help?
    Date
    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/

    \
     
     \ /
      Last update: 2005-03-22 14:00    [W:0.026 / U:0.844 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site