Rating: 
Summary: A Good introductory book
Review: Considering there are practically *no* books around that deals with debugger theory, I would label it a pioneering effort from Mr. Rosenberg.True that it side steps or do not discuss in detail issues which most debugger *writers* would want to know, I can understand why the author named the book 'How debuggers Work' instead of 'How to write debuggers' or 'Debugger writing: Principles and Techniques' etc. Still it gets you going and clear lots of necessary concepts.
Rating:
Summary: A well written introduction to a very complex topic
Review: I have to disagree with the author. The purpose of learning about writing a debugger is to "write a debugger". Because there aren't *any* other books with practical code and examples, the author missed a golden opportunity to fill a gap. My Win32 debugger has less than 200 lines of source code, so the assertion that debugger code is long and complex is completely false. The "concept" of debugging is a complex one, but the source code is not. That's not to say that the book is completely useless. Some of the advice given in the book can not be found in any other resource. And without it, it probably would have taken me much longer to write my debugger. Writing a debugger is not as easy as writing any other kind of program, so the concepts covered in the book are important. If you are interested in writing a Win32 debugger, my suggestion would be to get this book, but supplement it with an MSDN subscription (either online or on CDROM) and get the Microsoft Systems Journal CDROM with back-issues. With these three resources (and a LOT of patience) you'll be able to get your Win32 debugger up and running.
Rating: 
Summary: Good if you are only interested in theory and not practice
Review: I have to disagree with the author. The purpose of learning about writing a debugger is to "write a debugger". Because there aren't *any* other books with practical code and examples, the author missed a golden opportunity to fill a gap. My Win32 debugger has less than 200 lines of source code, so the assertion that debugger code is long and complex is completely false. The "concept" of debugging is a complex one, but the source code is not. That's not to say that the book is completely useless. Some of the advice given in the book can not be found in any other resource. And without it, it probably would have taken me much longer to write my debugger. Writing a debugger is not as easy as writing any other kind of program, so the concepts covered in the book are important. If you are interested in writing a Win32 debugger, my suggestion would be to get this book, but supplement it with an MSDN subscription (either online or on CDROM) and get the Microsoft Systems Journal CDROM with back-issues. With these three resources (and a LOT of patience) you'll be able to get your Win32 debugger up and running.
Rating:
Summary: Not recomended for anyone who wants source code
Review: I purchased this book because I needed to write a debugger for Win32. While it does give hints about the necessary API calls and processes, it does not provide any source code and avoided many advanced topics. I was highly disappointed.
Rating:
Summary: Not recomended for anyone who wants source code
Review: I purchased this book because I needed to write a debugger for Win32. While it does give hints about the necessary API calls and processes, it does not provide any source code and avoided many advanced topics. I was highly disappointed.
Rating: 
Summary: Superficial, Short: Skip it!
Review: I recall, as I worked on a large parallel Unix debugger, I always wondered why not a single book was written devoted to the architecture, design and implementation of symbolic debuggers. As I saw this book announced, my expectations were high. Could this be a help in organizing my knowledge about debuggers, collected so far from semi confidential industry reports or white papers, 3-4 dissertations, several implementations plus some 10-15 conference papers with vague descriptions of implementations, claims of spectacular achievements or just providing some pure theoretical ideas? This book, or rather "a booklet" is very incomplete. It literally did not told me any single detail which I would not have known already. For example, missing is the description of the very standard Unix interface to control and hold a process. Since this is not a scientific book providing more generic foundations about process tracing (such as tracking of very long time running programs, replay techniques, generating snapshots etc. etc.) than I would at least expect a solid practice orientation, including a complete discussion of several assemblers and typical architectures, because they provide sometimes completely different means of implementing breakpoints, watchpoints or supporting threads. I also miss the specifications and a good comparison of the two most common formats holding symbolic information (Stabs and DWARF.) In many cases a debugger must be or can be supported by a cooperating compiler and several interesting ideas have been implemented in the back-ends which may greatly help supporting breakpoints, finding function prologues, dealing with exceptions and asynchronous signals. etc. etc. this list could go on this way. Usually I call a book like this one "a blah blah novel." The author claims "I know something, but I will not tell what is it." Yes, there are debuggers, yes we can program them but a lot of code is necessary to do so, yes we can stop a process and advance it instruction by instruction. Yes, yes, I know all that. We will still have to wait a bit longer for a serious book about symbolic debugging.
Rating: 
Summary: Quite useful short book
Review: I think this book deserves reading, espesially if you are a beginner in corresponding field. It covers main aproaches to debugging, describes difficulties of debugging, briefly describes functionality, provided by Unix and Windows and it mentions future trends in this field. I think, taking into account nearly total absence of any structured information about this field of computer science, this book deserves reading.
Rating:
Summary: Very superficial, and moreover, fragmented
Review: If there were any alternative books on the topic, I'd give this one 1 star, rather than 3. But for some reason there aren't any, so one has to be extra charitable. The book is EXTREMELY superficial, badly structured, fragmentary, it truly looks like a few unrelated white papers written by a younger colleague/research assistant bound together and published under the head honcho's name, a hasty, half-hearted affair. Since this is the only thing in print covering the topic, you can't go wrong reading it, but don't expect to gain much. Perhaps working through the gdb's source code is better. Well, there's no question, of course, it's better because it's a real thing, but you might want to read this book as well, it does contain randomly located bits and pieces of relevant information. It would be really great if it were reworked: cleaned up, meaningfully structured, and given more depth (as well as source code.) Not sure why that's not done--such a book would definitely be commercially successful.
Rating:
Summary: A well written introduction to a very complex topic
Review: Kudos! I found this book to be insightful and informative. The hints about internal workings of debuggers gave me, as a software engineer, insights into how to write higher quality code. My use of debuggers is no longer shrouded in magic. Now I really understand what they're telling me.
Rating:
Summary: i liked this book very much
Review: This book has been real help to me in "designing implementation of symbolic debugger" as my b.e. final year project. This book has been a source of help in case of any problem i faced during my project.
| 
