This is the mail archive of the 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: Thread Specific Breakpoints in Remote Targets

> 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?

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?


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