Auto removing BPs on stop

Auto removing BPs on stop

[Fabian Cenedese]

Hi

Whenever the target stops gdb will remove all breakpoints from the target
and set them again before stepping/continuing. What functionality in gdb
depends on this? Backtrace? Breakpoint handling?
In our multitasking system a thread can stop on a breakpoint while the
others are still running, so the breakpoints are still useful and shouldn't
be removed.
What would break in gdb if I just removed those calls to unset/re-set
the breakpoints? I know that the setting is partly necessary as new
breakpoints aren't yet set.

Thanks

bye  Fabi

Re: Auto removing BPs on stop

[Daniel Jacobowitz]

On Fri, Sep 10, 2004 at 02:08:16PM +0200, Fabian Cenedese wrote:
> Hi
> 
> Whenever the target stops gdb will remove all breakpoints from the target
> and set them again before stepping/continuing. What functionality in gdb
> depends on this? Backtrace? Breakpoint handling?
> In our multitasking system a thread can stop on a breakpoint while the
> others are still running, so the breakpoints are still useful and shouldn't
> be removed.

GDB can't cope with this.  GDB assumes that when it is told that the
inferior has "stopped", its state will not change, and all threads can
be examined.

> What would break in gdb if I just removed those calls to unset/re-set
> the breakpoints? I know that the setting is partly necessary as new
> breakpoints aren't yet set.

I don't know.  A lot of places may still read target memory without
using the routines that "remove" breakpoints from GDB's image of target
memory, for one thing; this is slowly being fixed.

My goal is to stop the needless removing and reinserting some day, but
I don't think it will work yet.

-- 
Daniel Jacobowitz

Re: Auto removing BPs on stop

[Fabian Cenedese]

>> Whenever the target stops gdb will remove all breakpoints from the target
>> and set them again before stepping/continuing. What functionality in gdb
>> depends on this? Backtrace? Breakpoint handling?
>> In our multitasking system a thread can stop on a breakpoint while the
>> others are still running, so the breakpoints are still useful and shouldn't
>> be removed.
>
>GDB can't cope with this.  GDB assumes that when it is told that the
>inferior has "stopped", its state will not change, and all threads can
>be examined.

I know, that's the biggest obstacle in generally using gdb as debugger.
So far we had our own debugger which "just" used gdb for symbol lookups
and PC<->source resultions. I guess I need to stay that way for some
(long) time.

>> What would break in gdb if I just removed those calls to unset/re-set
>> the breakpoints? I know that the setting is partly necessary as new
>> breakpoints aren't yet set.
>
>I don't know.  A lot of places may still read target memory without
>using the routines that "remove" breakpoints from GDB's image of target
>memory, for one thing; this is slowly being fixed.
>
>My goal is to stop the needless removing and reinserting some day, but
>I don't think it will work yet.

I hoped I could at least move the breakpoint/single-step stuff from our
debugger to gdb as the routines in gdb are more advanced. I'll try
some more...

Thanks

bye  Fabi