Hi there!
I am very new to Linux kernel and if this is a question which is not for
this mailing list, please let me know.
I am trying to debug the kernel 2.6.11.2 with KGDB. I was able to
successfully debug linux kernel 2.6.7 on two machines (a P3, running as
a development machine, and the other is a dual Xeon 32-bit running as a
test machine) but I'm not able to configure 2.6.11.2 to enable KGDB.
There are no options available to enable KGDB (as opposed to 2.6.7) when
I run 'make menuconfig'. The kgdb.sourceforge.net site has kgdb patch
for 2.6.7 and not for later versions. Are there any patches or hooks
available to enable KGDB for linux-2.6.11.2?
I would really appreciate if someone could guide on the above query?
Thanks for your help,
Sameer
"Abhinkar, Sameer" <[email protected]> wrote:
>
> Are there any patches or hooks
> available to enable KGDB for linux-2.6.11.2?
kgdb patches are maintained in -mm kernels.
Patches are in
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.11/2.6.11-mm1/broken-out/*kgdb*
And the patch application order is described in
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.11/2.6.11-mm1/patch-series
On Thursday, March 17, 2005 1:54 pm, Andrew Morton wrote:
> "Abhinkar, Sameer" <[email protected]> wrote:
> > Are there any patches or hooks
> > available to enable KGDB for linux-2.6.11.2?
>
> kgdb patches are maintained in -mm kernels.
>
> Patches are in
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.11/2.6.11
>-mm1/broken-out/*kgdb*
>
> And the patch application order is described in
>
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.11/2.6.11
>-mm1/patch-series -
What's the latest status on these? Last I heard, some cleanup was going to
happen to make kgdb suitable for the mainline, did that ever happen? Also,
it would be nice if I could connect to a remote kernel running the kgdb stubs
w/o having to run gdb on the same ethernet segment. Would that be difficult
to fix?
Thanks,
Jesse
Jesse Barnes <[email protected]> wrote:
>
> > kgdb patches are maintained in -mm kernels.
> >
> > Patches are in
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.11/2.6.11
> >-mm1/broken-out/*kgdb*
> >
> > And the patch application order is described in
> >
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.11/2.6.11
> >-mm1/patch-series -
>
> What's the latest status on these? Last I heard, some cleanup was going to
> happen to make kgdb suitable for the mainline, did that ever happen?
It part-happened, then the effort seemed to die.
> Also,
> it would be nice if I could connect to a remote kernel running the kgdb stubs
> w/o having to run gdb on the same ethernet segment. Would that be difficult
> to fix?
<tries to remember how ethernet works>
Maybe we'd have to teach kgdboe to arp for the remote debug host. I think
Matt was talking about that a while back.
<tries to remember how ethernet switches work>
If switches send the destination MAC address through unchanged then maybe
the problem is that the switch simply doesn't know the MAC address of the
remote debug host yet? If the switch has its own MAC address (it doesn't,
does it), or if it's actually a router then perhaps you should specify the
router's MAC address and not the remote debug host's.
On Thu, Mar 17, 2005 at 02:29:58PM -0800, Andrew Morton wrote:
> Jesse Barnes <[email protected]> wrote:
> >
> > > kgdb patches are maintained in -mm kernels.
> > >
> > > Patches are in
> > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.11/2.6.11
> > >-mm1/broken-out/*kgdb*
> > >
> > > And the patch application order is described in
> > >
> > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.11/2.6.11
> > >-mm1/patch-series -
> >
> > What's the latest status on these? Last I heard, some cleanup was going to
> > happen to make kgdb suitable for the mainline, did that ever happen?
>
> It part-happened, then the effort seemed to die.
>
> > Also,
> > it would be nice if I could connect to a remote kernel running the kgdb stubs
> > w/o having to run gdb on the same ethernet segment. Would that be difficult
> > to fix?
>
> <tries to remember how ethernet works>
>
> Maybe we'd have to teach kgdboe to arp for the remote debug host. I think
> Matt was talking about that a while back.
>
> <tries to remember how ethernet switches work>
>
> If switches send the destination MAC address through unchanged then maybe
> the problem is that the switch simply doesn't know the MAC address of the
> remote debug host yet? If the switch has its own MAC address (it doesn't,
> does it), or if it's actually a router then perhaps you should specify the
> router's MAC address and not the remote debug host's.
I haven't tried this, but I believe you need to set up kgdboe's
destination MAC address as the MAC of the next IP hop. Switches should
be invisible to kgdboe.
--
Mathematics is the supreme nostalgia of our time.
On Thu, Mar 17, 2005 at 02:29:58PM -0800, Andrew Morton wrote:
> Jesse Barnes <[email protected]> wrote:
> >
> > > kgdb patches are maintained in -mm kernels.
> > >
> > > Patches are in
> > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.11/2.6.11
> > >-mm1/broken-out/*kgdb*
> > >
> > > And the patch application order is described in
> > >
> > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.11/2.6.11
> > >-mm1/patch-series -
> >
> > What's the latest status on these? Last I heard, some cleanup was going to
> > happen to make kgdb suitable for the mainline, did that ever happen?
>
> It part-happened, then the effort seemed to die.
Mutter, mutter, curse, mutter.
We got stuck on things like backtrace going on forever, and then trying
to find a way to get GDB to believe we want it to stop backtracing. I
think we've finally got that, in a way the GDB folks will approve and
won't horribly clutter the kernel.
We also got stuck on catching memory faults cleanly since it seems the
set_fs(KERNEL_DS) trick we used to use (and I swear worked), stopped
working around 2.6.10, but I haven't found time to go back and verify
when it stopped working.
--
Tom Rini
http://gate.crashing.org/~trini/