Hi Jason, Thanks for your reply.
I am more interested in kdb because, It does not required any tools[except for heperterminal] on host side [kgdb requires a linux pc] Will enter automatically on kernel crash/panic and gives option to dump some memory area. And to me Single stepping is not on the list. Dis-assembly is of lower priority. And Kdump requires configuration of another kernel. So kdb and lkcd look to suit our situation. And I have started with kdb and I am yet investigate more on lkcd. Thanks once again for your reply. Regards Basavaraj On Fri, Jun 12, 2009 at 11:16 PM, Jason Wessel <[email protected]>wrote: > Martin Hicks wrote: > > On Fri, Jun 12, 2009 at 06:00:46PM +0900, Basavaraj Dengi wrote: > > > >> Hi, > >> > >> After applying below patches > >> kdb-v4.4-2.6.24-common-2.bz2 > >> kdb-v4.3-2.4.20-xscale-1.bz2 > >> > > > > Are you really applying these two different patches? > > I really don't know what major changes happened between v4.3 and 4.4, > > but I'm not really shocked that things don't work. > > > > You might be on your own to get this working again. > > Jason Wessel has been working on getting KB to function as a front-end > > for KGDB. He posted patches to LKML about a month ago. They might be > > of interest to you. > > > > > > I doubt the whole armv7 instruction set was in the old xscale patch. > > In terms of the patch set Martin mentioned, the kdb front end code does > happen to work on ARM, but I had extra patches which I did not publish > which contained the logic for software single stepping on ARM. The > reason these were never published is that whole mess deserves a complete > re-write. There are traps that get placed and removed and ugly extra > exception logic in place. > > The right way to implement single stepping is to use the concept of out > of line instruction emulation such that you can execute the instruction > equivalent on a particular kernel thread and the final instruction would > be a trap to indicate the end of the out of line instruction execution. > > This allows you to do things like leave a breakpoint planted or truly > single step an individual kernel thread while not planting a breakpoint > in shared kernel code. This is a back burner project however at the > current time, unless someone else wants to contribute this logic or port > it from gdb. > > You might be better served to consider using kgdboc + gdb, if you want > to do some instruction disassembly. > > Jason. >
_______________________________________________ kdb mailing list [email protected] http://oss.sgi.com/mailman/listinfo/kdb
