Point #2 and #3 are what I had intended. > today. Typically this feature isn't very useful in the > kind of low-level > systems debugging we do in the kernel with kmdb and mdb > because you're > dealing with optimized, production code and your compiler > is free to reorder > things quite aggressively, making the assembly and source
Your point may be valid for core kernel developers, who have a good hang on SPARC assembly language. However I thought that it would be a useful feature for 3rd party driver developers, who develop code in high-level programming language and want it to work on multiple operating systems incl. Solaris. Anyway thanks Ivan, for passing on the mdb wishlist! BTW, NT has this feature and I have found driver developers, immensely using this:-) -vinodh > -----Original Message----- > From: Michael Shapiro [mailto:mws at sun.com] > Sent: Saturday, February 11, 2006 9:51 AM > To: vinodhs at hcl.in > Cc: mdb-discuss at opensolaris.org > Subject: Re: [mdb-discuss] source-level kernel debugging? > > > > > Does kmdb support source-level kernel debugging? > > > > Got out of Solaris work for quite sometime now, and just > catching up, > > with the latest developments. I know earlier debuggers like kadb had > > only assembly-level kernel debugging. > > Not sure what specifically you're looking for, but in general > people mean > one or more of three different things when they say > "source-level debugging": > > 1. The ability to view data structures in a source-level view > corresponding > to the data structure definitions of the source language. Both mdb > and kmdb offer this feature now. The ::print command can > be used to > print types, e.g. > > 0x12345678::print vnode_t > > and we have other commands like ::list that let you take > advantage of > source-level structure names, etc. This is all for C only > obviously. > > 2. The ability to correlate program counter offsets to > source-level file > names and line numbers. We don't offer this feature in > either mdb or kmdb > today. Typically this feature isn't very useful in the > kind of low-level > systems debugging we do in the kernel with kmdb and mdb > because you're > dealing with optimized, production code and your compiler > is free to reorder > things quite aggressively, making the assembly and source > not closely > correspond (it is for this reason that most compilers > disable some or all > optimization when you compile -g to get the offset->line > debug information). > That said, if someone wants to add DWARF processing for > this in a way which > is reasonable I wouldn't be opposed to it. > > 3. The ability to perform simple breakpoints and > breakpoint/step based on > source lines, implemented on top of #2. This is pretty > much entirely out > of whack with multi-threaded programming in general in my view, and > certainly with the low-level MT systems debugging that > mdb/kmdb are designed > for. A much better way to approach this is with DTrace, > where you can > dynamically examine MT systems behavior in a way that is > infinitely more > flexible and sophisticated than breakpoint-based debugging. > > In general, we use mdb for postmortem analysis and DTrace for > live system > analysis. Both of these tools and their accompanying > techniques, described > in the respective docs.sun.com manuals, are worth investing > the time to learn. > > -Mike > > -- > Mike Shapiro, Solaris Kernel Development. blogs.sun.com/mws/ > DISCLAIMER This message and any attachment(s) contained here are information that is confidential, proprietary to HCL Technologies and its customers. Contents may be privileged or otherwise protected by law. The information is solely intended for the individual or the entity it is addressed to. If you are not the intended recipient of this message, you are not authorized to read, forward, print, retain, copy or disseminate this message or any part of it. If you have received this e-mail in error, please notify the sender immediately by return e-mail and delete it from your computer
