From patchwork Thu Apr 13 12:09:11 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Pedro Alves X-Patchwork-Id: 20029 Received: (qmail 71681 invoked by alias); 13 Apr 2017 12:09:16 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Delivered-To: mailing list gdb-patches@sourceware.org Received: (qmail 71639 invoked by uid 89); 13 Apr 2017 12:09:15 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-25.1 required=5.0 tests=AWL, BAYES_00, GIT_PATCH_0, GIT_PATCH_1, GIT_PATCH_2, GIT_PATCH_3, RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.2 spammy=dig, 345 X-HELO: mail-wm0-f49.google.com Received: from mail-wm0-f49.google.com (HELO mail-wm0-f49.google.com) (74.125.82.49) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 13 Apr 2017 12:09:13 +0000 Received: by mail-wm0-f49.google.com with SMTP id t189so45443035wmt.1 for ; Thu, 13 Apr 2017 05:09:14 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=CX7CocBWm8BmmthrJdYQnsn/57Tcv7lmYp0jc3rd4Mg=; b=E4MLWxKxEuokLl31yjapLZ7FssZ8FZ4e1wZYSXY20QEgQcSpoXoFvMmYy6ErmFh70F VOnfBk+7Ke623J3Zj4CTdtQN53Am/ZPDskwyD29j0yKnfTvS8PnvKQMaaPwCl8kEZLsp JhJmdn9yAambUzSTISfAeQuneToJVVm1waK2r74N3UTKSw/HV/Xc3+KMByw2MKTbt31x R0k4eWD+xwI7PzfNe4+40OR5pMBOhF3Mjgjqc0Bb/5OWbPIKrTq3DUUEv13jZMscshqC DoIIUpeHFxQjuyFFQbyAT1iYGa2dt2TzRJ+zjmr/mZYGU/oyGsGJfCoN4ZUUBizJ+pNZ INBg== X-Gm-Message-State: AN3rC/6Z6aj+/FuAv2ocN6RNPkvzqsN579yNRuGogq1A+lkcN6f+6jiR lJVML/QnUoxDpAREAvK60A== X-Received: by 10.28.105.92 with SMTP id e89mr2836562wmc.93.1492085352834; Thu, 13 Apr 2017 05:09:12 -0700 (PDT) Received: from [192.168.0.101] ([37.189.166.198]) by smtp.gmail.com with ESMTPSA id 201sm10367916wmr.5.2017.04.13.05.09.11 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 13 Apr 2017 05:09:12 -0700 (PDT) Subject: Re: [PATCH 2/8] Fix follow-fork latent bug To: Yao Qi References: <1491954673-29172-1-git-send-email-palves@redhat.com> <1491954673-29172-3-git-send-email-palves@redhat.com> <86a87kaasz.fsf@gmail.com> Cc: gdb-patches@sourceware.org From: Pedro Alves Message-ID: <1dcfd9ba-e360-c94b-b089-9c4e8be15def@redhat.com> Date: Thu, 13 Apr 2017 13:09:11 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <86a87kaasz.fsf@gmail.com> On 04/13/2017 10:58 AM, Yao Qi wrote: > Pedro Alves writes: > >> - old_chain = save_inferior_ptid (); >> - save_current_program_space (); >> + old_chain = save_current_space_and_thread (); >> >> inferior_ptid = child_ptid; >> add_thread (inferior_ptid); >> + set_current_inferior (child_inf); >> child_inf->symfile_flags = SYMFILE_NO_READ; > > Can we set up child thread_info inferior and pspace first, and then, > call switch_to_thread_no_regs to switch them in one go? Although it seemingly works, and I tried this patch on top of the series: I don't think I'd like to do that (at least not now), because it doesn't look like clone_program_space and solib_create_inferior_hook really work correctly if called without switching the current inferior to point to the child. For example, I set a breakpoint on current_inferior, active while GDB is running clone_program_space, and with "set detach-on-fork off" for example, we get many hits which currently (it looks to me incorrectly) refer to the parent inferior instead of the child inferior that is loading symbols. Here's a sample: (top-gdb) bt #0 0x00000000006c2baa in current_inferior() () at src/gdb/inferior.c:59 #1 0x00000000006a5026 in set_target_gdbarch(gdbarch*) (new_gdbarch=0x19aba30) at src/gdb/gdbarch.c:5438 #2 0x00000000005b21ac in set_gdbarch_from_file(bfd*) (abfd=0x1193540) at src/gdb/arch-utils.c:620 #3 0x000000000067f2a8 in exec_file_attach(char const*, int) (filename=0x1894a30, from_tty=0) at src/gdb/exec.c:383 #4 0x0000000000729985 in clone_program_space(program_space*, program_space*) (dest=0x1c8d3a0, src=0x11e8de0) at src/gdb/progspace.c:193 #5 0x00000000006c571a in follow_fork_inferior(int, int) (follow_child=0, detach_fork=0) at infrun.c:527 (top-gdb) bt #0 0x00000000006c2baa in current_inferior() () at src/gdb/inferior.c:59 #1 0x00000000005b66f5 in invalidate_auxv_cache() () at src/gdb/auxv.c:345 #2 0x000000000070f705 in observer_executable_changed_notification_stub(void const*, void const*) (data=0x5b66ec , args_data=0x7fffffffd028) at ./observer.inc:364 #3 0x000000000070ef72 in generic_observer_notify(observer_list*, void const*) (subject=0x11085e0, args=0x7fffffffd028) at src/gdb/observer.c:167 #4 0x000000000070f796 in observer_notify_executable_changed() () at ./observer.inc:387 #5 0x000000000067f316 in exec_file_attach(char const*, int) (filename=0x1894a30 "gdb/testsuite/outputs/gdb.base/foll-fork/foll-fork", from_tty=0) at src/gdb/exec.c:399 #6 0x0000000000729985 in clone_program_space(program_space*, program_space*) (dest=0x1c8d3a0, src=0x11e8de0) at src/gdb/progspace.c:193 I'd rather not have to dig into this area too deeply at this point. Thanks, Pedro Alves diff --git c/gdb/infrun.c w/gdb/infrun.c index fcafdc1..3c5f583 100644 --- c/gdb/infrun.c +++ w/gdb/infrun.c @@ -500,9 +500,7 @@ holding the child stopped. Try \"set detach-on-fork\" or \ old_chain = save_current_space_and_thread (); - inferior_ptid = child_ptid; - add_thread (inferior_ptid); - set_current_inferior (child_inf); + add_thread (child_ptid); child_inf->symfile_flags = SYMFILE_NO_READ; /* If this is a vfork child, then the address-space is @@ -629,9 +627,7 @@ holding the child stopped. Try \"set detach-on-fork\" or \ this new thread, before cloning the program space, and informing the solib layer about this new process. */ - inferior_ptid = child_ptid; - add_thread (inferior_ptid); - set_current_inferior (child_inf); + add_thread (child_ptid); /* If this is a vfork child, then the address-space is shared with the parent. If we detached from the parent, then we can @@ -657,6 +653,8 @@ holding the child stopped. Try \"set detach-on-fork\" or \ the core, this wouldn't be required. */ solib_create_inferior_hook (0); } + + switch_to_thread (child_ptid); } return target_follow_fork (follow_child, detach_fork);