Re: [PATCH] Re: bug in mi when setting breakpoint

[Vladimir Prus <ghost@cs.msu.su>]

On Sunday 20 January 2008 13:38:05 Nick Roberts wrote:

>  > 3. Assuming we have a list of breakpoints (which Eclipse and KDevelop
>  > do), we surely can delete breakpoints there. However, adding unwanted
>  > breakpoints right away will not be good in non-stop mode:
>  >
>  >   - Some threads might already stop on unwanted breakpoints before you
>  >   delete them 
>  >   - You might run out of hardware resources while setting unwanted
>  >    breakpoints
> 
> Running GDB in "non-stop mode" sounds highly ambitious and may happen a long
> time in the future, if at all.

I'm not sure if you saw an announcement about non-stop mode project. It's
rather near future.

> I'm talking about implementing a simple 
> solution, for now.  Even if non-stop mode does become a reality, it presumably
> won't be the default behaviour, so it won't break existing front ends.

This does not mean that all MI commands should behave differently in non-stop mode.

>  > I think it's more clear to set only those breakpoints that user want to set,
>  > as opposed to setting all of them, and then removing undesired ones.
> 
> Yes, but I still haven't see how you propose to do this.

-break-insert, in case when there are several overloaded functions, should return
this:

   ^error,msg="Several overloaded functions found",
	functions=["int f(int)", "int f(double)"]

then, break-insert should have an -o parameter that specifies a list of overloaded
functions to set breakpoints on:

  -break-insert -o 0 f

- Volodya