This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: Thread Specific Breakpoints in Remote Targets
- From: Tom Tromey <tromey at redhat dot com>
- To: Josh Watt <jpewdev at gmail dot com>
- Cc: Pedro Alves <pedro at codesourcery dot com>, gdb at sourceware dot org
- Date: Wed, 05 Oct 2011 11:23:26 -0600
- Subject: Re: Thread Specific Breakpoints in Remote Targets
- References: <CAEPrYjQnadK872r5dXz2-KFBsoXcpBj0CMPc3gcSmtAvcrUBpg@mail.gmail.com> <201108311909.22045.pedro@codesourcery.com> <CAEPrYjQnsDy1z=d5f5K36v-HnL8-bpm-vdwH4wscXBK7uKv7sA@mail.gmail.com> <201108311942.00429.pedro@codesourcery.com> <CAEPrYjTxvbCTp=rC1syxdYQ5xoy-BeovXtro-gnZNJrWz_C+SA@mail.gmail.com>
>>>>> "Josh" == Josh Watt <jpewdev@gmail.com> writes:
[ thread-specific breakpoints on the target ]
Josh> Unless I'm missing something, I don't believe this would be too
Josh> difficult to implement. Most of the code would live in remote.c and
Josh> would require a new packet for handling thread breakpoints.
I didn't see a response to this.
Josh> Would something like this be OK, or did you have something else in mind?
Josh> vThreadBreak;addr;kind;thread-id
Josh> The only other question I currently have is how should the thread id
Josh> be communicated to remote.c? Should the global inferior_ptid be used,
Josh> or would we add another member to the struct bp_target_info that
Josh> contains the thread ID?
I don't know the details of the remote protocol, but yes, something like
this would be good to have. On the gdb side, I would say adding a field
to bp_target_info would be much better than a global.
Tom