Messages in this thread | | | Date | Wed, 8 Feb 2012 01:51:21 +0400 | From | Cyrill Gorcunov <> | Subject | Re: [PATCH] ptrace: add ability to get clear_tid_address |
| |
On Tue, Feb 07, 2012 at 09:15:07PM +0000, Pedro Alves wrote: > On 02/07/2012 08:56 PM, Cyrill Gorcunov wrote: > > On Tue, Feb 07, 2012 at 08:07:38PM +0000, Pedro Alves wrote: > >> On 02/03/2012 04:51 PM, Oleg Nesterov wrote: > >>> On 02/03, Pavel Emelyanov wrote: > >> > >>>> Because there's no need for current to get this value of himself, but can > >>>> be useful for e.g. gdb. > >>> > >>> OK, perhaps this makes sense, I do not know. > >>> > >>> Jan, Pedro, do you think gdb can use PTRACE_GET_TID_ADDRESS (returns > >>> tracee->clear_child_tid) ? > >> > >> Off hand, I'm not picturing a use. But that may well just mean I'm lacking > >> imagination. Andrew, Pavel, did you have a particular idea in mind when you > >> said it may be useful for debugging a multithreading program / gdb? > >> > > > > Might not we set up hw watchpoint on this address and get interrupt > > before pthread-join will find it? (To be fair I'm not sure if such > > trick will work, didn't test ;) > > For a debugger wanting to know when a pthread_join was about to return? > Might be simpler to put a breakpoint (or stap probe, or some such) inside > pthread_join.
Yes, could be, but it means you have to install pthread debug libs, right? (have no idea actually since I personally use debug printing instead of breakpoints).
> It's the kernel that writes to this address, so I've no > idea if the watchpoint trap ends up visible on userspace. Which thread > would it be reported to, given that this is cleared when the child > is gone, I have no idea either.
Yeah, need some help from someone who wrote hw-breakpoints support in kernel (i don't remember the details).
Cyrill
| |