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: RFA [PATCH v4] Implement 'catch syscall' for gdbserver (was Re: RFA [PATCH v3] Implement 'catch syscall' for gdbserver)


On 09/29/2013 12:04 PM, Philippe Waroquiers wrote:
ChangeLog
2013-xx-yy  Philippe Waroquiers  <philippe.waroquiers@skynet.be>

	* NEWS: Document new QcatchSyscalls packet and its use
	in x86/amd64 linux gdbserver and Valgrind gdbserver.
	* remote.c (PACKET_QCatchSyscalls): New.
	(remote_protocol_features): Add QcatchSyscalls.
	(remote_set_syscall_catchpoint): New function.
	(remote_parse_stop_reply): New stop reasons syscall_entry
	and syscall_return.
	(init_remote_ops): Registers remote_set_syscall_catchpoint
	and the config commands for PACKET_QCatchSyscalls.

I'm late to the party, but i've always wondered why we have all these different "insert_<foo>_catchpoint" and "remove_<foo>_catchpoint" functions to accomplish tasks that seem to be very similar in nature.

Not saying we should go this route for this patch, but we may want to consider a more generic RSP packet for catchpoints. Something like the following:

QInsertCatchpoint:[syscall|fork|exec|vfork|unload|...]
QRemoveCatchpoint:[syscall|fork|exec|vfork|unload|...]

... or even communicate catchpoints through Z/z packets, though that would be a more radical approach.

Anyway, just throwing a few ideas since i've been dealing with some of the issues with catchpoints, forking and gdbserver as well.


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