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: [linux] fix stepping over fork in follow-child mode.


Daniel Jacobowitz wrote:

> On Tue, Mar 18, 2008 at 08:46:46PM +0000, Pedro Alves wrote:
>> Hi,
>> 
>> I noticed that issuing a next over a fork call, with
>> "follow-fork-mode child", wasn't working.  The problem is that when we
>> update the breakpoints in the child to attach them to the current thread
>> if their thread their currently attached to doesn't exist anymore,
>> inferior_ptid doesn't hold the tid yet.
> 
> Here's an alternative fix.  Vladimir, this is also the patch I was
> talking about earlier on IRC.  Not tested or finished yet.
> 
> The basic idea: we only use tids for two things.  We display them to
> the user and we pass them to libthread_db.  So the problematic
> Linux behavior in which the tid is not available immediately for
> the first thread (not until libpthread.so has initialized, to be
> precise) is not a problem if we remove the tid from the ptid_t.
> Instead, Linux now always puts zero there.  This lets us delete
> a lot of code that was already more or less dead, save some
> operations, et cetera.
> 
> NULL thread_info->private should never happen when libpthread.so's
> pthread_create is used to create new threads.  That's where most of
> the FIXMEs are for this patch; they're in places where if linux-nat.c
> detects a newly cloned process, we don't have thread_info->private
> filled in.  I think the right thing to do is to fill it in lazily
> by calling td_ta_map_lwp2thr et cetera, and to handle it being NULL
> for clones the thread manager doesn't know about.
> 
> I can work on this some more tomorrow, but you wanted a preview :-)

I guess this is too smart code for me to try to understand before you
wake. Just a couple of questions:

1. Your patch seem to remove thread_db_resume, including this
bit of code in it:

          if (GET_PID (ptid) == -1)
            inferior_ptid = lwp_from_thread (inferior_ptid);
          else if (is_thread (ptid))
            ptid = lwp_from_thread (ptid);

What was the code, and in particular the last line, trying to do,
and why we don't actually have to do this?

2. It seems that some other modules use tid. In particular,
aix-thread.c makes use of the ptid_get_tid call. What to do about that?

- Volodya



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