Breakpoints

[Niko Sams]

On Wed, Apr 15, 2009 at 9:43 PM, Andreas Pakulat <apaku at gmx.de> wrote:
> 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?
ok so:
Don't save breakpoints per run-config, but filter them.
That way C++ breakpoints are shared across targets, but Php
breakpionts are hidden
when debugging a C++ target.


Niko