This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: Thread Specific Breakpoints in Remote Targets
- From: Josh Watt <jpewdev at gmail dot com>
- To: Pedro Alves <pedro at codesourcery dot com>
- Cc: gdb at sourceware dot org
- Date: Thu, 1 Sep 2011 10:33:48 -0500
- 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>
> There's that backwards compatibility thing. ?You'd have to come up with
> a way to get the current behavior of "breakpoint applies to all threads
> of this process". ?You'd need to add some new meaning to something
> like Hg0/HgPID.0, which is close, but that's not what it means
> today, so without other changes, you'd be left with the target not
> knowing what this particular gdb is trying to say (because you don't
> know whether the connecting gdb understands "thread specific" or not).
Makes sense.
Unless I'm missing something, I don't believe this would be too
difficult to implement. Most of the code would live in remote.c and
would require a new packet for handling thread breakpoints.
Would something like this be OK, or did you have something else in mind?
vThreadBreak;addr;kind;thread-id
The only other question I currently have is how should the thread id
be communicated to remote.c? Should the global inferior_ptid be used,
or would we add another member to the struct bp_target_info that
contains the thread ID?
--
~JPEW