Breakpoints

[Andreas Pakulat]

On 15.04.09 23:31:50, Vladimir Prus wrote:
> On Wednesday 15 April 2009 22:57:09 Niko Sams wrote:
> 
> > I have another use-case:
> > a project with 2 unit-tests (2 targets). If I switch the target I don't want to
> > loose all breakpoints
> 
> Where the breakpoints are? If they are in the unit tests proper, then it's
> fine if they per-config. If they are in a shared library, or code that is 
> otherwise shared between unit tests, then indeed, we better have this 
> breakpoint stick. 
> 
> In other words, giving a list of *all* breakpoints and a debug session, there
> should be a way to classify each breakpoint as either:
> 
> 1. Breakpoint that is inserted
> 2. Breakpoint that is not inserted yet, but might be inserted when some shared
>   lib is loaded
> 3. Breakpoint that run into a hard problem
> 4. Breakpoint that is not relevant to debug session
> 
> 1 and 3 are easy -- it is distingushing 2 and 4 that is hard. Note that Eclipse
> also tries to do that -- it has "Show breakpoints Supported By Selected Target"
> button in breakpoint window -- but the code that tries to guess that is scary.
> 
> Maybe, as 0-th approximation we can group breakpoints by programming language?

Thats something that I thought of as well right now (while writing the
response just before this). Its obviously really easy to find out the
mimetype for a given file in which the breakpoint is, the hard part is
deciding which mimetypes are supported by a given launch config. Especially
the "native application" one has a possibly huge list (c, c++, ada,
fortran, haskell, native-compiled java, ...). But maybe this is something
the debugger plugin should provide, i.e. given a launch config type it can
tell me which mimetype the files it can set breakpoints on are supported?

I still dream of gdb support also handling ada/fortran etc. just as gdb
itself can (AFAIK).

Andreas

-- 
You have many friends and very few living enemies.