Re: Debugger Info

"Paul Pluzhnikov" <>
24 Jul 2002 01:50:47 -0400

          From comp.compilers

Related articles
Debugger Info (shamanth) (2002-07-21)
Re: Debugger Info (Paul Pluzhnikov) (2002-07-24)
Re: Debugger Info (M.G.J. van den Brand) (2002-07-25)
Re: Debugger Info (Joachim Durchholz) (2002-07-25)
Re: Debugger Info (Marco van de Voort) (2002-07-31)
Re: Debugger Info (Momchil Velikov) (2002-07-31)
Re: Debugger Info (Sander Vesik) (2002-07-31)
Re: Debugger Info (Paul Pluzhnikov) (2002-08-04)
[1 later articles]
| List of all articles for this month |

From: "Paul Pluzhnikov" <>
Newsgroups: comp.compilers
Date: 24 Jul 2002 01:50:47 -0400
Organization: EarthLink Inc. --
References: 02-07-085
Keywords: debug
Posted-Date: 24 Jul 2002 01:50:47 EDT

"shamanth" <> writes:

> I am entrusted with designing of source level debugger. so I would
> like you to suggest some options which y'all have appreciated the most
> while debugging also some options which you felt were needed but not
> provided.

I spend most of my time debugging at a very low level on multiple
platforms ... I use gdb for most of it, just so I do not have to
re-learn all the debugger commands on all the platforms.

Here are the features of gdb which I use every day:
- ability to stop on shared library load/unload
- ability to do hardware watchpoints
- ability to set break points (BP) on instruction address
- ability to query functions/variables with regexp
- conditional BPs
- 'thread apply all'

Here are the features that gdb lacks, or misfeatures (it may
well be that the feature is actually present, but I do not know
about it -- feel free to enlighten me ;-):
- unable to set break points in DSO until that DSO has been
    loaded (makes debugging static constructors rather tricky)
- unable to re-insert breakpoints on functions without debug info
    upon process restart
- sets BPs incorrectly on functions compiled with non-standard
    prolog (e.g. -fomit-frame-pointer on x86)
- no general programmability or access to internals, e.g. can't
    write something like this:

      eval `some-external-command $currentPID $currentTID $currentBP`

- weak support for DSOs, e.g. if function foo is present (without
    debug info) in a.elf, and, setting BP on`foo
    without knowing its address is impossible (I think).

- weak (but improving) support for debugging multi-threaded programs
- weak support for debugging fork()ing or exec()ing programs
- more often than not unable to decode stack trace on alpha or MIPS.

Here are gripes I have with other debuggers:

- HP-UX xdb -- can't set BP on functions without debug info (^&%$#!!!)
- HP-UX dde -- totally unusable in non-GUI mode, very unintuitive
    in GUI mode
- MS DevStudio6
    [things have improved a bit in VC.Net, but I have not
    spent enough time with it to comment on them]
    -- doesn't even have non-GUI mode ;-(

    Layout changes, menus disappear depending on 'mode' -- whether you
    have an inferior process or not, whether it is stopped or not.

    Can't set a skip-count on a BP above 32767. God help you if you
    need to stop on 1000001st call to foo().

    As you walk up or down the stack, 'Registers' and 'Disassembly'
    windows are not updated to reflect current level. Disassembling
    code in anything but the current frame requires manual decoding
    of %EBP chain and dragging the right address into the 'Disassembly'

    Unable to understand casts involving '**', e.g. in 'Watch window':
    *(char **)ip [it treats ** as exponentiation].

- dbx (solaris, AIX)
    Missing 'thread apply all' -- try printing stack traces for all threads
    when there are 200 of them.

In order to understand recursion you must first understand recursion.

Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.