Customer Reviews

How Debuggers Work: Algorithms, Data Structures, and Architecture

5 star:		(3)
4 star:		(1)
3 star:		(5)
2 star:		(0)
1 star:		(2)

 

 

I recall the time, as I worked on a large parallel Unix debugger, and only slowly collected facts and scraps of necessary knowledge to progress. I always wondered, why not a single book was written, which would be solely 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 with mere theoretical ideas?

No, unfortunately this is not so. 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. This should include a complete discussion of several assemblers and typical architectures, because they provide sometimes completely different means of implementing breakpoints, watchpoints or of support for threads. In many cases a debugger must be, or can be supported by a cooperating compiler. 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. I also miss the specifications and a good comparison of the two most common formats holding symbolic information, Stabs and DWARF! Etc. etc., this list of missing facts and issues could go on and on.

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.

I think that will have to keep waiting for a serious book about symbolic debugging! Any takers? If I only could write well...

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.

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.

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 this book 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.

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.

If you're fairly new to software development and want a general survey of how debuggers work, and perhaps some tips on how to use them, this book may be of use to you.

I'm about to start work with a new employer on a tool chain for a new chip. I had hoped to gain some insight about debugger internals. Unfortunately, this book was not useful for me, and I actually wish I could get my money back.

Notice also that this book was published in 1996 (if I recall correctly). While much of what it covers is "timeless" (again, if you're looking for a survey book), large patches of the book are wasted on obsolete issues like debugging in Windows 95, or debugging 16-bit processes in a 32-bit Windows OS.

This is a good introductory book on debuggers, but for those who need the modern, deep details as well as information on pioneering into the new debugging methods of the cutting edge (reverse debugging support in gdb and Visual Studio 2010 for instance), we need a more detailed reference.

I would like to work with this author and/or anyone else who would care to contribute on developing a book to fill that need. Please feel free to contact me (my email address is public on my Amazon profile) if you'd like to collaborate or contribute or partner. I will gladly publicly acknowledge anyone who helps or gives their opinions or ideas.

- Warric

This book was a disappointment. It doesn't even come close to describing modern debuggers. I'm still waiting for a good book to be published on debuggers.

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.

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.