This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] Disable thread specific breakpoints when thread dies


On Mon, Nov 14, 2005 at 11:32:00AM +0000, Andrew STUBBS wrote:
> Daniel Jacobowitz wrote:
> >But about the actual patch...
> >
> >I'd like to minimize the amount that GDB plays with the user visible
> >state of breakpoints.  Can we arrange to just not insert breakpoints,
> >if they are thread-specific to a dead thread?  I think that'll work
> >too.
> 
> So you want to disable it 'unofficially'? I suppose that would be 
> preferable, but I wouldn't know that best way to achieve it. I'll have a 
> look though.

I'm thinking about a check in insert_breakpoints, just before calling
insert_bp_location.  By the !breakpoint_enabled.  This may have other
side effects, so it would need testing.

> GDB already plays with watchpoints (deletes them in fact). At least it 
> did in 6.3. That said I wouldn't complain if somebody 'fixed' them so 
> that they were reinstated when the program returned to the right context.

Yes, exactly.

Just to clarify: yes, I acknowledge that what you're doing here is
similar to many other places that GDB messes with the state, e.g.
shlib_disabled.  But I've been looking on and off at overhauling our
breakpoint management, and this is one of the bits that I really want
to go away.  If we want to display to the user "sorry, right now I
believe this breakpoint can not/should not be inserted, so I'm not
going to", then it shouldn't show up as "disabled".  

I want to decrease the total number of interactions.

-- 
Daniel Jacobowitz
CodeSourcery, LLC


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]