Recent

Author Topic: Books and Articles on building a debugger  (Read 1462 times)

valdir.marcos

  • Hero Member
  • *****
  • Posts: 999
Books and Articles on building a debugger
« on: January 10, 2020, 04:18:04 am »
What books or articles on writing a debugger do you suggest?

I am searching for books and articles on writing a debugger, but I could only find:

How Debuggers Work, Jonathan B. Rosenberg. Wiley, 1996
Gray Hat Python – Python Programming for Hackers and Reverse Engineers, Justin Seitz, 2009
Debugging Visual C++ Windows, Keith Bugg, 1998



A debugger from scratch — part 1
Using ptrace to set a breakpoint in an executable
Liz Rice, 2018
https://medium.com/@lizrice/a-debugger-from-scratch-part-1-7f55417bc85f
https://medium.com/@lizrice/a-debugger-from-scratch-part-2-9954006850bd

How debuggers really work
You've probably used a debugger to check your code, but do you know how they do what they do?
Levente Kurusa, 2018
https://opensource.com/article/18/1/how-debuggers-really-work

Writing a basic Windows debugger, Ajay Vijayvargiya, 2011
https://www.codeproject.com/Articles/43682/Writing-a-basic-Windows-debugger
https://www.codeproject.com/Articles/132742/Writing-Windows-Debugger-Part-2
« Last Edit: January 10, 2020, 10:15:45 am by valdir.marcos »

howardpc

  • Hero Member
  • *****
  • Posts: 3528
Re: Books and Articles on building a debugger
« Reply #1 on: January 10, 2020, 09:54:41 am »
How many books and articles would prove sufficient for you?  :)

valdir.marcos

  • Hero Member
  • *****
  • Posts: 999
Re: Books and Articles on building a debugger
« Reply #2 on: January 10, 2020, 10:18:31 am »
How many books and articles would prove sufficient for you?  :)
I am still searching for something that consider Pascal existence.

howardpc

  • Hero Member
  • *****
  • Posts: 3528
Re: Books and Articles on building a debugger
« Reply #3 on: January 10, 2020, 11:59:32 am »
You may have to write that book or article yourself.
Marc Weustink and Martin Friebe have been two of the most prominent contributors to the Lazarus debuggers.
Perhaps you could collaborate on some new documentation?

JdeHaan

  • Jr. Member
  • **
  • Posts: 59
Re: Books and Articles on building a debugger
« Reply #4 on: January 10, 2020, 12:54:27 pm »
A full coded (Java) example is given in:

Writing Compilers and Interpreters – third edition
A software engineering approach
by Ronald mak

In Ch13 - "an interactive source level debugger", it's worked out in detail.


valdir.marcos

  • Hero Member
  • *****
  • Posts: 999
Re: Books and Articles on building a debugger
« Reply #5 on: January 12, 2020, 04:28:47 am »
You may have to write that book or article yourself.
Marc Weustink and Martin Friebe have been two of the most prominent contributors to the Lazarus debuggers.
Perhaps you could collaborate on some new documentation?
I am trying to make both ends meet.

valdir.marcos

  • Hero Member
  • *****
  • Posts: 999
Re: Books and Articles on building a debugger
« Reply #6 on: January 12, 2020, 04:31:56 am »
A full coded (Java) example is given in:

Writing Compilers and Interpreters – third edition
A software engineering approach
by Ronald mak

In Ch13 - "an interactive source level debugger", it's worked out in detail.
Very nice catch.
Thanks.

valdir.marcos

  • Hero Member
  • *****
  • Posts: 999
Re: Books and Articles on building a debugger
« Reply #7 on: January 12, 2020, 05:39:00 am »
It seems I have discovered why Niklaus Wirth didn't talk about debuggers on his books:

"We started designing the system in late fall 1985, and programming in early 1986. As a vehicle we used our workstation Lilith and its language Modula-2. First, a cross-compiler was developed, then followed the modules of the inner core together with the necessary testing and down-loading facilities. The development of the display and the text system proceeded simultaneously, without the possibility of testing, of course. We learned how the absence of a debugger, and even more so the absence of a compiler, can contribute to careful programming."
Project Oberon: the Design of an Operating System and Compiler, Niklaus Wirth, 1992.

Before Borland Turbo Pascal, it also seems that Pascal book writers didn't like the debugger idea, but most C and C++ book writers do.

I don't like debuggers. Never have, probably never will. I use gdb all the time, but I tend to use it not as a debugger, but as a disassembler on steroids that you can program.

None of the arguments for a kernel debugger has touched me in the least.
And trust me, over the years I've heard quite a lot of them. In the end, they tend to boil down to basically:

 - it would be so much easier to do development, and we'd be able to add new things faster.

And quite frankly, I don't care. I don't think kernel development should be "easy". I do not condone single-stepping through code to find the bug.
I do not think that extra visibility into the system is necessarily a good thing.

Apparently, if you follow the arguments, not having a kernel debugger leads to various maladies:
 - you crash when something goes wrong, and you fsck and it takes forever and you get frustrated.
 - people have given up on Linux kernel programming because it's too hard and too time-consuming
 - it takes longer to create new features.

And nobody has explained to me why these are _bad_ things.

To me, it's not a bug, it's a feature. Not only is it documented, but it's _good_, so it obviously cannot be a bug.

"Takes longer to create new features" - this one in particular is not a very strong argument for having a debugger. It's not as if lack of features or new code would be a problem for Linux, or, in fact, for the software industry as a whole. Quite the reverse. My biggest job is to say "no" to new features, not trying to find them.

Oh. And sure, when things crash and you fsck and you didn't even get a clue about what went wrong, you get frustrated. Tough. There are two kinds of reactions to that: you start being careful, or you start whining about a kernel debugger.

Quite frankly, I'd rather weed out the people who don't start being careful early rather than late. That sounds callous, and by God, it _is_ callous. But it's not the kind of "if you can't stand the heat, get out the the kitchen" kind of remark that some people take it for. No, it's something much more deeper: I'd rather not work with people who aren't careful. It's darwinism in software development.

It's a cold, callous argument that says that there are two kinds of people, and I'd rather not work with the second kind. Live with it.

I'm a bastard. I have absolutely no clue why people can ever think otherwise. Yet they do. People think I'm a nice guy, and the fact is that I'm a scheming, conniving bastard who doesn't care for any hurt feelings
or lost hours of work if it just results in what I consider to be a better system.

And I'm not just saying that. I'm really not a very nice person. I can say "I don't care" with a straight face, and really mean it.

I happen to believe that not having a kernel debugger forces people to think about their problem on a different level than with a debugger. I think that without a debugger, you don't get into that mindset where you know how it behaves, and then you fix it from there. Without a debugger, you tend to think about problems another way. You want to understand things on a different _level_.

It's partly "source vs binary", but it's more than that. It's not that you have to look at the sources (of course you have to - and any good debugger will make that _easy_). It's that you have to look at the level _above_ sources. At the meaning of things. Without a debugger, you basically have to go the next step: understand what the program does. Not just that particular line.

And quite frankly, for most of the real problems (as opposed to the stupid bugs - of which there are many, as the latest crap with "truncate()" has shown us) a debugger doesn't much help. And the real problems are what I worry about. The rest is just details. It will get fixed eventually.

I do realize that others disagree. And I'm not your Mom. You can use a kernel debugger if you want to, and I won't give you the cold shoulder because you have "sullied" yourself. But I'm not going to help you use one, and I wuld frankly prefer people not to use kernel debuggers that much. So I don't make it part of the standard distribution, and if the existing debuggers aren't very well known I won't shed a tear over it.

Because I'm a bastard, and proud of it!
Linus
Linus Torvalds, Availability of kdb, 06 Sep 2000
https://lkml.org/lkml/2000/9/6/65
https://news.ycombinator.com/item?id=19460381


Quote from: astrobe
Perhaps not as specific as you think:

    If debugging is the process of removing software bugs, then programming must be the process of putting them in.
-- E. Dijkstra

    If you want more effective programmers, you will discover that they should not waste their time debugging, they should not introduce the bugs to start with.
-- E.Dijkstra

    Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it.
-- B. Kernighan

    The most effective debugging tool is still careful thought, coupled with judiciously placed print statements.
-- B. Kernighan

Basically what they say is that, against bugs, we use a defense-in-depth strategy:

    Correct by design (KISS, formal proofs)
    Correct by implementation (coding standards, code reviews)
    Correct by the proof of the pudding (testing and debugging)

Testing doesn't demonstrate the absence of bugs. It can only prove that there is a bug. Debugging is one of the last line of defense before the bug goes into production. You should avoid making it a usual thing by any mean.

And it's not just old (or dead) grey beards doing things the old way: recent languages like Ocaml, Haskell, Rust really try hard to make the first line of defense stronger.
https://www.reddit.com/r/linux/comments/b48irs/linus_torvalds_i_dont_like_debuggers_never_have/


"I do not use a debugger."
Daniel Lemire, 2016
https://lemire.me/blog/2016/06/21/i-do-not-use-a-debugger/

valdir.marcos

  • Hero Member
  • *****
  • Posts: 999
Re: Books and Articles on building a debugger
« Reply #8 on: January 12, 2020, 06:03:08 am »
When I was very young, I had a boss [former COBOL programmer] that got used to seat side by side with me to design all logic on paper before the first line to be typed on the computer [Computer Associates Clipper]. It was called "table test" or something similar. ("teste de mesa" in Portuguese).
He always remembered me that when he was young and had learned to program in COBOL, he was not aloud to "waste" the hard disc retyping things not perfectly done in the first try after thinking and putting everything on paper...
He used to emphasized that good programmers should think much more [and understand the whole] than type...

440bx

  • Hero Member
  • *****
  • Posts: 2000
Re: Books and Articles on building a debugger
« Reply #9 on: January 12, 2020, 08:13:04 am »
A good debugger is an absolutely essential tool no matter _who_ says otherwise. 

It's not a matter of debugging your own code.  When you are trying to figure out what _somebody_ else's code is actually doing (which can be very different than what the original programmer thought it does) a debugger is, by far, the most effective way of analyzing a piece of software.

There was a time when SoftICE (a system debugger) was available for Windows.  Whenever you wanted to really know what some Windows API _actually_ did (which is _not_ the same as what MS says it does) all you needed was to code a call to the API of interest and step through the call in SoftICE.

People who don't like debuggers are trying to HIDE THEIR bugs from other programmers.  I stand by that whether the person is Linus Torvald, Edgar Dijkstra or any other computer science "god" who claims otherwise. 

A good debugger is an essential tool in a programmer's toolbox, not just for debugging but for testing and analyzing code.  You want to know what your O/S is doing ?... use a system debugger (truth serum for software.)


FPC v3.0.4 and Lazarus 1.8.2 on Windows 7 64bit.

simone

  • Sr. Member
  • ****
  • Posts: 356
Re: Books and Articles on building a debugger
« Reply #10 on: January 12, 2020, 11:35:44 am »
A full coded (Java) example is given in:

Writing Compilers and Interpreters – third edition
A software engineering approach
by Ronald mak

In Ch13 - "an interactive source level debugger", it's worked out in detail.

I also recommend this book, which I bought some time ago, having been impressed by the author's choice to use Pascal as a compiler target language. Very nice, although the use of Java to write a compiler is not common in the real world, considering that compilers that are not self hosted are usually written in C/C++.

About usefulness of debuggers, at least for debug my code, the tool I have most often is 'writeln'.  :D
« Last Edit: January 12, 2020, 01:13:35 pm by simone »
Microsoft Windows 10 64 bit - Lazarus 2.0.10

Martin_fr

  • Administrator
  • Hero Member
  • *
  • Posts: 6628
  • Debugger - SynEdit - and more
    • wiki
Re: Books and Articles on building a debugger
« Reply #11 on: January 12, 2020, 11:45:41 am »
What books or articles on writing a debugger do you suggest?

What do you hope to learn from the book?

Microsoft has documentation on their API: https://docs.microsoft.com/en-us/windows/win32/debug/writing-the-debugger-s-main-loop
Linux: man ptrace

Debug info (dwarf): http://dwarfstd.org/
For stabs, I do not have a link.
There also other formats, if you use other compilers. It's a matter of finding each spec (I doubt a single book will include all the different specs).

You also need info on the exe format. (elf, pe....). Again google...

Info on watchpoints is hardware specific. For intel, it can again be found by google (debug register DR6 or DR7).

Reading asm, stack-unrolling, etc => all CPU dependent.

As for calling functions in the target app, you may need the ABI / calling-conventions of each system on which you debug. (Or have a look at what FPC does / compile to asm)


The other site is: What features should a debugger offer.

Or what strategies are there to debug, and how to complement the strategies with a matching set of features....
« Last Edit: January 12, 2020, 11:48:06 am by Martin_fr »

JdeHaan

  • Jr. Member
  • **
  • Posts: 59
Re: Books and Articles on building a debugger
« Reply #12 on: January 12, 2020, 03:07:51 pm »
A couple of years ago I translated the Java code from the book
"Writing Compilers and Interpreters – third edition, A software engineering approach" into Pascal (at least up to chapter 17). Just put it on GitHub:

https://github.com/jdehaan2014/pascal_intp_comp

You need the book to understand the code since I almost translated 1-to-1 from Java to Pascal, and further I didn't document the code... (I know)

 

TinyPortal © 2005-2018