Re: PPC KGDB changes and some help?

["Amit S. Kale" <amitkale@emsyssoft.com>]

On Thursday 22 Jan 2004 9:15 pm, Tom Rini wrote:
> On Thu, Jan 22, 2004 at 09:25:19AM -0600, Hollis Blanchard wrote:
> > On Jan 22, 2004, at 9:07 AM, Tom Rini wrote:
> > >On Wed, Jan 21, 2004 at 03:12:25PM -0800, George Anzinger wrote:
> > >>A question I have been meaning to ask:  Why is the arch/common
> > >>connection
> > >>via a structure of addresses instead of just calls?  I seems to me
> > >>that
> > >>just calling is a far cleaner way to do things here.  All the struct
> > >>seems
> > >>to offer is a way to change the backend on the fly.  I don't thing we
> > >>ever
> > >>want to do that.  Am I missing something?
> > >
> > >I imagine it's a style thing.  I don't have a preference either way.
> >
> > I think we in PPC land have gotten used to that "style" because we have
> > one kernel that supports different "platforms", i.e. it selects the
> > appropriate code at runtime as George says. In general that's a little
> > bit slower and a little bit bigger.
> >
> > Unless you need to choose among PPC KGDB functions at runtime, which I
> > don't think you do, you don't need it...
>
> That's certainly true, so if (and if I understand Georges question
> right) Amit wants to change kgdb_arch into a set of required functions,
> with stubs in, say, kernel/kgdbdummy.c, (and just keep the flags / etc
> in the struct), that's fine with me.

The penalty of keeping them consolidated in a structure isn't so high. I 
prefer to keep them that way. I'll work on reducing number of initialization 
functions, though.

I have to do something about early connect though. Powerpc kgdb on 8260 is 
definitely capable of starting debugging right at architecture setup time. 
It's just that kgdbstub.c isn't ready yet.

How about changing the code in kgdbstub to allow kgdb to be configured in one 
of the following ways:
Late kgdb - kgdb comes up after smp_init in the kernel boot sequence. kgdb8250 
can be used with more flexibility through kernel command line options. One 
can boot a kgdb kernel without activating kgdb. Works with the interface 
chosen by kernel command line (kgdb8250 and kgdbeth for the moment).

Command line flexibilty is of great help if you have to test on 2-3 servers (I 
used to do that a lot at Veritas). The same kernel can be compiled with 
drivers needed by all of them plus kgdb. Command line options choose port no 
and speeds depending on machine hardware connections. I guess it's of little 
use on embedded systems where usually a new kernel has to be compiled for 
each board.

Early kgdb - kgdb comes up right at the begining of start_kernel at the cost 
of flexibility. It doesn't show any messages such as "waiting for gdb". All 
configurations have to be compiled in through menuconfig. Once a kernel is 
built, it'll always run with kgdb and with 8250 at a fixed port and speed.

i386 architecture will support both kgdb configuration.
KGDB in powerpc 8260 will be of early kgdb type. Other powerpc arches (550 etc 
will depend on whether the interface can be initialized early or later)
-- 
Amit Kale
EmSysSoft (http://www.emsyssoft.com)
KGDB: Linux Kernel Source Level Debugger (http://kgdb.sourceforge.net)