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: [RFC][Patch] Fix gdb failure to access tls data for parent thread


On Tuesday 24 February 2009 15:31:53, Daniel Jacobowitz wrote:
> 81 ? ? ? ? ? ?/* Verify that this thread's pid field matches the child PID.
> 82 ? ? ? ? ? ? ? If its pid field is negative, it's about to do a fork or it
> 83 ? ? ? ? ? ? ? is the sole thread in a fork child. ?*/

Boo, I'm on glibc 2.7, which doesn't have this check, but I see it
in glibc-2.9 sources...

> It's checking that the PID (not TID) matches proc_handle.pid. ?We need
> to find another way to read from a stopped thread, since if we put any
> other PID there, we get no threads. ?I would suggest expanding
> ps_prochandle to include a memory thread as ptid_t. ?

Right, I'll take this.  Funny, I was actually noticing the other day
that the proc service implementation in sol-threads.c passes a ptid
already, and I was considering making sol-threads.c use proc-service.c:

 /* This struct is defined by us, but mainly used for the proc_service
    interface.  We don't have much use for it, except as a handy place
    to get a real PID for memory accesses.  */

 struct ps_prochandle
 {
   ptid_t ptid;
 };

> We always try to 
> read from the most recently added stopped thread, since the lwp_list
> gets additions at the front.
> 


-- 
Pedro Alves


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