Feature level 0.1:

• A basic Workspace is needed where you can:
• Add source links (in a tree view)
• Store settings for a project (breakpoints, layouts, executable, parameters, etc)

Mark a function or some # lines of code and record the execution flow history for some given amount of hits or time period.

Feature level for 0.1:

• Set breakpoints at given source/line location (error handling of this doesn't need to be super good at this point if source/line doesn't match current executable)
• Stepping: Single step, step in, step out, run until
• Stop current running program
• Continue
• Abort
• Load executable with set working directory and command line

Of the program being debugged

Feature so when you are inside a loop you can setup out from it and the continue the execution after the loop

Using either script or some other nice way (like struct descriptor also should work)

Frontend UI should be built around splitviews as seen in the ProDG debugger.

Breakpoint filtering based on callstack, e.g. don't break in the future from this callstack.
Also, break only with current callstack from now on.

Just got around to try to build the project, and got stuck on the qt version(s).

I downloaded the Qt 5.2.0 version and set the QT5 env var to that folder (Qt/5.2.0/clang_64), which makes it find the bin folder, but unfortunately not the QtWidgets include. This is easy to understand since apparently, the installer for Qt5.2 stopped shipping all the includes(!?). The Qt5.1.0 installer contains all include folders, but then Qt won't build on OSX 10.9 (it seems to only support 10.8).

So I tried building the source from Qt/5.2.0/Src/qtbase, but running make install gave me the same missing include folders. I've reached the highest level of success by setting the QT5 to the Src/qtbase directory since the bin and includes are there. However, then I get a build error:

qmetatype.h:2040:97: error: declaration requires an exit-time destructor [-Werror,-Wexit-time-destructors]
QtMetaTypePrivate::QPairVariantInterfaceConvertFunctor > f(o);

Any suggestions on how to "build from scratch" ? I propose adding these build notes to the readme for future readers.

Regards,
Mathias

Basic TTY view that listens to stdout from the process being debugged. Very basic similar to VS

Bookmarks in memory view. Both on an address and on selection of bytes. (Something like HexFiend on OSX)

Where you can type in actions with completion etc

This to support for 0.1:

• Show accurate disassembly (from native and remote)
• Switchable in the source view with space
• Register highlighting
• No mix source/disassembly for 0.1

Basic list of all the breakpoints with possibility to enable/disable a breakpoint (checkbox)
Adding a breakpoint in the source view should show up in this list and vice versa.

Supported types for 0.1

• File/Line
• Address
• Data breakpoint

File/Line

Address

Pressing new breakpoint button should give a request with something like this

Data breakpoint in list

Feature level for 0.1:

• Show the current locals in the function being debugged
• Support edit simple types (ints, floats, etc)

Feature Level for 0.1:

• Very Similar to the locals view but you should be able to watch variables (similar to watches in ProDG/Visual Studio)

• Add variables to watch should be possible and look something like this

Unfolding of variables with changed color if values has changed

Sometimes you see code like this:

MyFunc(a->Width(), a->Height(), a->Bla(), b->Foo());

Using the usual "Step Into" will take you to all kinds of functions you might not care about and is super tedious. A new "Step Into Function" should step into the last function called on the line: MyFunc..

With expressions and what not

With scrub-able timeline. Would be very awesome but almost impossible to implement (at least for native) some emulated targets may be possible to handle this

Breakpoints on a per thread basis, better views of the current thread being debugged

Viewing float* as vec4 for example

Like MSVC autoexp.dat but way better

Features for 0.1:

Should be possible to switch thread in the thread view. For 0.1 I don't think we need to support freezing and such of threads. Switch thread should be reflected correctly in the callstack view also.

Or to scripting language so it can be used by doing small steps for doing stuff

gdb supports this

Similar to Maya for example with MEL as you can then use these commands to script stuff

Feature level should be similar to ProDG/Visual Studio

Selecting another entry in the in the callstack should send an event that all other views can listen to (locals needs to switch variables, registers needs to be updated etc)

Callstack should support symbols just as well as addresses.

String searching, numbers (in various formats)

For example in JSON, etc (optional) to make it possible to script complex cases and give and allow processing of the data

Feature level for RemoteAPI:

• The remote API is a simple API that allows debugging of "Remote" Targets over TCP/IP using a simple message sending system. For one example there is a examples/Fake6502 included which shows how to debug an emulated 6502 CPU
• Stepping : step in, out, etc (worth to notice that its up to the remote api to implement them correctly but ProDBG should be able to send the data)
• Request memory, disassembly, exception location

Support for basic stylesheet theme with parser + token substitution of colours\sizes

Alternate line colours for memory views as default, but with the ability to instead specify a stride for colouring.

Hotkeys for going to next 'start of block' would be nice.

Debugger should support (but not enforce) that parts of code can be (re)loaded without restarting the debugging session.

http://bitsquid.blogspot.se/2011/08/idea-for-better-watch-windows.html

When debugging display the value of the in parameters for a given function when you are debugging and also what kind of data a function will be called with at a callsite

See this for inspiration: http://www.youtube.com/watch?v=-YZUGJaaasE#t=12m50s

Features for 0.1:

• Have basic version of Source Code View working with Scintilla. A fair amount of work has been done here already but needs some more fixes before it can be considered 0.
• Goto line
• Search text
• Hover var and expand (very similar to locals view but on top of the source view similar to VS)

Pause thread(s), step specific thread(s), and step "across" threads on context switch (as if single core).

Ideas from here http://visualstudiogallery.msdn.microsoft.com/4a979842-b9aa-4adf-bfef-83bd428a0acb

Handy when doing loading, looking at memory, etc

Ability to install a lightweight service\listener on a target machine, and provide most - if not all - debugging features from a remote machine running the ProDBG application.

Features for 0.1:

• View, edit and look at any (accessible) part of the memory.
• Show memory as basic types (u8, s16, u16, u32, floats, doubles, etc)

Pretty much it should support what Visual Studio Memory Viewer supports.

• #232
• #233
• #234
• #235
• #236
• #237
• #238
• #239
• #240
• #241
• #242
• #243
• #244
• #245