Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cdt-dev] Breakpoints in assembly

> Hi!
> Is there a planned freeze date for the next release off the head? That's 
> the quite handy feature!

Well, we will gather the features, bug/PR etc ... we got from
the usual sources (Bugzilla, email, newsgroups, marketing, etc ...)
and come up with a list of things that are feasible for the next round.
A quick glimpse, of some of the stuff we got in line:

- Disassembly view (Work in progress)
   * breakpoint address
   * extends ASMEditor

- Function Breakpoint (need a better C/C++ parser)
   * Reuse the outline view

- Shared library views

- Enable Contribution by the mi.ui plugin  to ILaunch
  For example tod gdb specific commands like "add-syms"

- SourceLocator (work in progress)
  * Prompt user for source code outside the workspace

- Formatting of the Variable Values.

- Globals variable(need a better C/C++ parser model):
  * COFF parser, no way to get globals 
  * gdb is to verbose(for threads +500 globals).

- When using the gdb prompt console(Driving the debugger via the console
  instead of the UI) make the UI aware of certain
  commands (stepping, breakpoint settings etc ..) (Work in progress)

- Fix nasty side effect in the hoverring:
  if you hilight over,
  i.e. hilight "i" __and__ "++".

  The evaluating expression will __execute__ "i++", with the side
  effect of changing the value of "i", ... really undesirable.

  The rationale was to use the gdb feature "call"  to make
  a call to the inferior, for example hilighting and hover on it
    getpid()  --> return the pid of the process.
  i.e. hilight "getpid" __and__ "()".

- Examples, code and documentation, on how to use the CDI interface.

- ...

I'll try to post a more complete list in the following weeks.  Meanwhile
send your features/requests via bugzilla or emails.

Back to the top