-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Content-Type: text/plain; charset=us-ascii
ftp://oss.sgi.com/projects/kdb/download/ix86/kdb-v1.9-2.4.16.bz2
ftp://oss.sgi.com/projects/kdb/download/ia64/kdb-v1.9-2.4.16-ia64-011128.bz2
Ethan Solomita ([email protected]) has done a port of kdb to
sparc64 against 2.4.13. I will upgrade that to 2.4.16, integrate it
with the other kdb changes since 2.4.13 and release it in a few days.
This will probably be the last release of kdb using this patch format.
I plan to split kdb into a core patch and smaller arch dependent
patches, instead of one big patch for each arch.
Changelog extract.
2001-12-03 Keith Owens <[email protected]>
* Upgrade to 2.4.16.
* Add include/asm-um/kdb.h stub to allow XFS to be tested under UML.
* Check if an interrupt frame on i386 came from user space.
* Out of scope bug fix in kdb_id.c. Ethan Solomita.
* Changes to common code to support sparc64. Ethan Solomita.
* Change GFP_KERNEL to GFP_ATOMIC in disasm. Ethan Solomita.
2001-11-16 Keith Owens <[email protected]>
* Upgrade to 2.4.15-pre5.
* Wrap () around #define expressions with unary operators.
2001-11-13 Keith Owens <[email protected]>
* Upgrade to 2.4.15-pre4.
* kbdm_pg.c patch from Hugh Dickins.
2001-11-07 Keith Owens <[email protected]>
* Upgrade to 2.4.14-ia64-011105.
* Change name of l1 serial I/O routine, add ia64 init command. SGI.
* Sync kdbm_pg with XFS.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.4 (GNU/Linux)
Comment: Exmh version 2.1.1 10/15/1999
iD8DBQE8CxeSi4UHNye0ZOoRAg5XAJ0X38pwRAQn626kA52x3blkPqJEZQCfYFZf
uEs8b9QtISbATIBWtO44H/M=
=01s4
-----END PGP SIGNATURE-----
On Mon, Dec 03, 2001 at 05:11:31PM +1100, Keith Owens wrote:
> This will probably be the last release of kdb using this patch format.
> I plan to split kdb into a core patch and smaller arch dependent
> patches, instead of one big patch for each arch.
Why can't you release one kdb patch instead?
Christoph
--
Of course it doesn't work. We've performed a software upgrade.
On Mon, 3 Dec 2001 08:43:10 +0100,
Christoph Hellwig <[email protected]> wrote:
>On Mon, Dec 03, 2001 at 05:11:31PM +1100, Keith Owens wrote:
>> This will probably be the last release of kdb using this patch format.
>> I plan to split kdb into a core patch and smaller arch dependent
>> patches, instead of one big patch for each arch.
>
>Why can't you release one kdb patch instead?
Because every architecture except i386 differes from the base kernel.
IA64 has its own large patch set that has to be applied to the main
kernel before kdb can be applied. Sparc uses the vger kernel tree.
The -ac trees are different again.
Keith,
I have a naive question.
Is there any chance to be merged into Linus's linux?
If not, why? If yes, when?
Thanks in advance,
Hiro
From: Keith Owens <[email protected]>
Subject: [Linux-ia64] Announce: kdb v1.9 is available for kernel 2.4.16
Date: Mon, 03 Dec 2001 17:11:31 +1100
Message-ID: <[email protected]>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Content-Type: text/plain; charset=us-ascii
>
> ftp://oss.sgi.com/projects/kdb/download/ix86/kdb-v1.9-2.4.16.bz2
> ftp://oss.sgi.com/projects/kdb/download/ia64/kdb-v1.9-2.4.16-ia64-011128.bz2
>
> Ethan Solomita ([email protected]) has done a port of kdb to
> sparc64 against 2.4.13. I will upgrade that to 2.4.16, integrate it
> with the other kdb changes since 2.4.13 and release it in a few days.
>
> This will probably be the last release of kdb using this patch format.
> I plan to split kdb into a core patch and smaller arch dependent
> patches, instead of one big patch for each arch.
>
> Changelog extract.
>
> 2001-12-03 Keith Owens <[email protected]>
>
> * Upgrade to 2.4.16.
> * Add include/asm-um/kdb.h stub to allow XFS to be tested under UML.
> * Check if an interrupt frame on i386 came from user space.
> * Out of scope bug fix in kdb_id.c. Ethan Solomita.
> * Changes to common code to support sparc64. Ethan Solomita.
> * Change GFP_KERNEL to GFP_ATOMIC in disasm. Ethan Solomita.
>
> 2001-11-16 Keith Owens <[email protected]>
>
> * Upgrade to 2.4.15-pre5.
> * Wrap () around #define expressions with unary operators.
>
> 2001-11-13 Keith Owens <[email protected]>
>
> * Upgrade to 2.4.15-pre4.
> * kbdm_pg.c patch from Hugh Dickins.
>
> 2001-11-07 Keith Owens <[email protected]>
>
> * Upgrade to 2.4.14-ia64-011105.
> * Change name of l1 serial I/O routine, add ia64 init command. SGI.
> * Sync kdbm_pg with XFS.
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.0.4 (GNU/Linux)
> Comment: Exmh version 2.1.1 10/15/1999
>
> iD8DBQE8CxeSi4UHNye0ZOoRAg5XAJ0X38pwRAQn626kA52x3blkPqJEZQCfYFZf
> uEs8b9QtISbATIBWtO44H/M=
> =01s4
> -----END PGP SIGNATURE-----
>
>
> _______________________________________________
> Linux-IA64 mailing list
> [email protected]
> http://lists.linuxia64.org/lists/listinfo/linux-ia64
On Tue, 04 Dec 2001 10:50:51 +0900,
Hiro Yoshioka <[email protected]> wrote:
>I have a naive question.
>Is there any chance (kdb) to be merged into Linus's linux?
>If not, why? If yes, when?
http://www.lib.uaa.alaska.edu/linux-kernel/archive/2000-Week-36/0575.html
http://marc.theaimsgroup.com/?l=linux-kernel&m=96865229622167&w=2
>>>>> "keith" == Keith Owens <[email protected]> writes:
keith> On Mon, 3 Dec 2001 08:43:10 +0100,
keith> Christoph Hellwig <[email protected]> wrote:
>> On Mon, Dec 03, 2001 at 05:11:31PM +1100, Keith Owens wrote:
>>> This will probably be the last release of kdb using this patch format.
>>> I plan to split kdb into a core patch and smaller arch dependent
>>> patches, instead of one big patch for each arch.
>>
>> Why can't you release one kdb patch instead?
keith> Because every architecture except i386 differes from the base kernel.
keith> IA64 has its own large patch set that has to be applied to the main
keith> kernel before kdb can be applied. Sparc uses the vger kernel tree.
keith> The -ac trees are different again.
That is bad, now that you are able to create a kernel that will
compile in i386 & ia64 with latest ia64 patch, I will also like to
be able to integrate kdb there with support for both archs.
Later, Juan.
--
In theory, practice and theory are the same, but in practice they
are different -- Larry McVoy
[email protected] said:
> http://www.lib.uaa.alaska.edu/linux-kernel/archive/2000-Week-36/0575.html
> http://marc.theaimsgroup.com/?l=linux-kernel&m=96865229622167&w=2
The answer, of course, is to do all your debugging in the MIPS kernel, which
even in Linus' tree contains gdb stubs, although I think Linus' tree is
missing the gdbconsole which sends all printk output as GDB $O packets.
(gdb) tar rem /dev/ttyS0
Remote debugging using /dev/ttyS0
0x80110070 in breakinst ()
(gdb) cont
Continuing.
CPU revision is: 00002721
FPU revision is: 00002720
Primary instruction cache 16KiB.
Primary data cache 16KiB.
Secondary cache 256KiB, linesize 32 bytes.
Enabling secondary cache...Done
Tertiary cache present, not (yet) enabled
TLB has 64 entries.
Linux version 2.4.16-0.4 ([email protected]) (gcc version
While I sort of see Linus' point, there are two cases where it falls down
most often for me.
Firstly, roughly half the bugs which I track by poking around with GDB are
caused by toolchain/compiler problems, not by bogus code. Looking at the
code and thinking hard does _not_ help you here. You have to see what's
buggered, compare the code with the asm and slowly find out what went wrong.
If BUG() contains a breakpoint and you can poke at it all immediately,
that's a _lot_ easier than forty-five recompilations and reboots with extra
printks in random places, the final one of which changes the compiler's
output so it no longer exhibits the same bug.
Secondly, the point about not having a debugger making you more careful may
be true - but half the time I track bugs, they're not in my own code. In
fact, I'd go as far as to say the 99% of the bugs I actually use GDB for
aren't in my own code. Some _other_ bugger has been careless, and I'm here
trying to pick up the pieces.
(Sorry for taking the bait - but anything's better than the evolution thread)
--
dwmw2
>
>
>
> While I sort of see Linus' point, there are two cases where it falls down
> most often for me.
Actually, I don't see any part of Linus' point. Kdb is a tool, just as
much as vi or cscope are tools that aid in kernel development. Anyone
who would throw away a useful tool because he doesn't think it is pretty
(or that a tool should be used at all) is a fool.
The biggest advantage to kdb is its ability to help understand code
more quickly than just reading it. The ability to stop at a particular
point and see how you got there can aid in the process of learning the
source and the multitude of pathways through the code.
Additionally, one can often repair a defect by modifying a register
and continuing, thus increasing productivity over debug techniques that
include printk() and reboot.
scott
>
> Firstly, roughly half the bugs which I track by poking around with GDB are
> caused by toolchain/compiler problems, not by bogus code. Looking at the
> code and thinking hard does _not_ help you here. You have to see what's
> buggered, compare the code with the asm and slowly find out what went wrong.
> If BUG() contains a breakpoint and you can poke at it all immediately,
> that's a _lot_ easier than forty-five recompilations and reboots with extra
> printks in random places, the final one of which changes the compiler's
> output so it no longer exhibits the same bug.
>
> Secondly, the point about not having a debugger making you more careful may
> be true - but half the time I track bugs, they're not in my own code. In
> fact, I'd go as far as to say the 99% of the bugs I actually use GDB for
> aren't in my own code. Some _other_ bugger has been careless, and I'm here
> trying to pick up the pieces.
>
> (Sorry for taking the bait - but anything's better than the evolution thread)
>
> --
> dwmw2
>