[
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++;
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.