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 remote.c


CVSROOT:	/cvs/src
Module name:	src
Changes by:	palves@sourceware.org	2013-01-25 17:25:59

Modified files:
	gdb            : ChangeLog remote.c 

Log message:
	Fix GDB internal error against targets that return a thread in T stop replies but don't support qC.
	
	Yao writes:
	
	~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
	
	GDB gets an internal error when it connects to GDBserver started with
	'--disable-packet=qC'.
	
	Sending packet: $QNonStop:0#8c...Packet received: OK
	Sending packet: $?#3f...Packet received: T0505:00000000;04:00f0ffbf;08:b0c2e44c;thread:p4255.4255;core:1;
	Sending packet: $Hc-1#09...Packet received: E01
	Sending packet: $qC#b4...Packet received:
	Sending packet: $qAttached:a410#bf...Packet received: E01
	Packet qAttached (query-attached) is supported
	warning: Remote failure reply: E01
	Sending packet: $qOffsets#4b...Packet received:
	../../../git/gdb/target.c:3248: internal-error: Can't determine the current address space of thread Thread 16981
	
	When start remote, the call chain is as follows,
	
	remote_start_remote
	add_current_inferior_and_thread <--[1]
	...
	start_remote
	wait_for_inferior
	remote_wait_as
	process_stop_reply
	get_thread_arch_regcache   <--[2]
	remote_notice_new_inferior <--[3]
	
	GDB sends packet "qC" in [1] and adds the thread/inferior if the remote
	stubs understands "qC".  In [2], GDB looks for the inferior to build a
	regcache, and notices a new inferior in [3].  As we can see, GDB assumes
	that the inferior can be found in [2].  Once the remote stub doesn't
	support "qC", GDB can't look for the inferior in [2], and emits an
	internal error.
	
	~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
	
	Right after the initial connection, we query the target for its state,
	with the ? packet.  We store the resulting wait status / stop reply
	aside, and query the target for the current thread, using qC, which
	fails, so we fake a ptid for the target's thread.  We then later,
	after the initial setup, end up consuming that set-aside wait status,
	parsing the T stop reply, which contains a "thread" "register" (which
	was the thread the target would have replied to qC).  We get into
	trouble because the ptid in that stop reply doesn't match our faked up
	ptid in the initial setup, although the target threads are the same...
	
	So we had the T stop reply handy all along.  We might as well extract
	the thread's ptid from it, and avoid all the resulting issues.
	
	qC is also used after vRun, in order to discover the new process'es
	main thread.  But, vRun's reply is also a wait status, just like
	'?''s, which is quite convenient.
	
	This means that if we have a "Txx thread: ptid" reply, then we don't
	really need qC.  The patch makes GDB look in the T reply first, and if
	not found, try with qC.  The packet handling seems to have been added
	in gdb-4.18 (1999), and I see that in that same release, "Txx thread:
	ptid" didn't exist yet, which probably explains why nobody though of
	doing this before.
	
	Regression tested against a gdbserver with qC disabled (and then
	enabled), on x86_64 Fedora 17.
	
	2013-01-25  Pedro Alves  <palves@redhat.com>
	
	* remote.c (stop_reply_extract_thread): New.
	(add_current_inferior_and_thread): New parameter 'wait_status'.
	Handle it.
	(remote_start_remote): Pass wait status to
	add_current_inferior_and_thread.
	(extended_remote_run): Update comment.
	(extended_remote_create_inferior_1): Pass wait status to
	add_current_inferior_and_thread.

Patches:
http://sourceware.org/cgi-bin/cvsweb.cgi/src/gdb/ChangeLog.diff?cvsroot=src&r1=1.15070&r2=1.15071
http://sourceware.org/cgi-bin/cvsweb.cgi/src/gdb/remote.c.diff?cvsroot=src&r1=1.521&r2=1.522


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