This is the mail archive of the gdb-cvs@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]

src/gdb ChangeLog breakpoint.c


CVSROOT:	/cvs/src
Module name:	src
Changes by:	palves@sourceware.org	2013-09-19 14:45:33

Modified files:
	gdb            : ChangeLog breakpoint.c 

Log message:
	Fix regressions caused by thread-specific breakpoint deletion.
	
	The recent change to make GDB auto-delete thread-specific breakpoints
	when the corresponding thread is deleted
	(https://sourceware.org/ml/gdb-patches/2013-09/msg00038.html) caused
	gdb.base/nextoverexit.exp to regress.
	
	Breakpoint 1, main () at .../gdb/testsuite/gdb.base/nextoverexit.c:21
	21        exit (0);
	(gdb) next
	[Inferior 1 (process 25208) exited normally]
	Thread-specific breakpoint -5 deleted - thread 1 is gone.
	Thread-specific breakpoint -6 deleted - thread 1 is gone.
	Thread-specific breakpoint -7 deleted - thread 1 is gone.
	Thread-specific breakpoint 0 deleted - thread 1 is gone.
	(gdb) FAIL: gdb.base/nextoverexit.exp: next over exit (the program exited)
	
	We shouldn't be seeing this for internal or momentary breakpoints.  In
	fact, we shouldn't even be trying to delete them, as whatever created
	them will take care or it, and therefore it's dangerous to delete them
	behind the creator's back.
	
	I thought it'd still be good to tag thread-specific internal/momentary
	breakpoints such that we'll no longer try to keep them insert in the
	target, as they'll cause stops and thread hops in other threads, so I
	tried disabling them instead.  That caused a problem when following a
	child fork, and detaching from the parent, as we try to reset the
	step-resume etc. breakpoints to the new child's thread
	(breakpoint_re_set_thread), after the parent thread is already gone
	(and the breakpoints are marked disabled).  I fixed that by
	re-enabling internal/momentary breakpoints there, but, that didn't
	feel super safe either (maybe we'd need a new flag in struct
	breakpoint instead, to tag the thread-specific breakpoint as "not to
	be inserted").  It felt like I was heading down a design rat hole,
	and, other things will usually delete internal/momentary breakpoints
	soon enough, so I left that little optimization for some other day.
	
	So, internal/momentary breakpoints are no longer deleted/disabled at
	all, and we end up with a one-liner fix.
	
	Tested on x86_64 Fedora 17.
	
	gdb/
	2013-09-19  Pedro Alves  <palves@redhat.com>
	
	* breakpoint.c (remove_threaded_breakpoints): Skip non-user
	breakpoints.

Patches:
http://sourceware.org/cgi-bin/cvsweb.cgi/src/gdb/ChangeLog.diff?cvsroot=src&r1=1.16015&r2=1.16016
http://sourceware.org/cgi-bin/cvsweb.cgi/src/gdb/breakpoint.c.diff?cvsroot=src&r1=1.777&r2=1.778


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