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

-
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.122 / U:0.316 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site