From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4768 invoked by alias); 30 Oct 2019 01:46:31 -0000 Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org Received: (qmail 4755 invoked by uid 89); 30 Oct 2019 01:46:30 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.1 spammy=H*f:sk:d0d526d, HX-Languages-Length:4384, dear X-HELO: mail-qk1-f196.google.com Received: from mail-qk1-f196.google.com (HELO mail-qk1-f196.google.com) (209.85.222.196) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 30 Oct 2019 01:46:29 +0000 Received: by mail-qk1-f196.google.com with SMTP id e2so1041516qkn.5 for ; Tue, 29 Oct 2019 18:46:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=Uo++d0KHjUj2gN/+ZaD9FqTcy29PIut6GUnwRP9OU0w=; b=r/HudaDFv2daoZsHJA+WOtnlK1QMvHIzwlRpoDaJHQ6Q9vOSp/bU01VXMnCOCgX7aV axjbc1Cecwvq7jhrwADiNo9nm++QOmzxZCkD+i3z/E/bMExHBp3AuPRYDo9UJJOgfKV0 c1rK93Q+yRhOvcyOgCA8wbY1goZp0mm6SycVdhK7KB1DUJbrEGAJmvhnx0xYaRz/takt FxUxtq5Vha5UxkcGEwBSGK45mUbDXOIuTd3gTcRM0mdAIJeJSUpBURj77echHjilCB/4 IumSasF9b0F2cm7dyLHfgLaDVmH71Ym2tZ2f7LnIX5PiA6G8Lg3Nj4x9WsFaWau1lWiT 2Ksw== Return-Path: Received: from [192.168.15.21] (201-42-175-128.dsl.telesp.net.br. [201.42.175.128]) by smtp.gmail.com with ESMTPSA id d126sm497428qkc.93.2019.10.29.18.46.24 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 29 Oct 2019 18:46:25 -0700 (PDT) Subject: Re: gdbserver for arm does not support multi-process debugging To: =?UTF-8?B?5YiY5bq3?= Cc: gdb@sourceware.org References: <6fea79cd.5d47.16dd85f053a.Coremail.lkang0305@163.com> <73071c36-cbe3-aacf-36fe-4097dc6a0817@linaro.org> <3cb2ee7c.59f4.16dfc404ae2.Coremail.lkang0305@163.com> <934889b6-c654-76ab-a4ca-48b515e24859@linaro.org> <1eb012d5-2fad-bd49-e5c9-6160bbfc1c0d@linaro.org> <57533fd3.e9a7.16e171c601e.Coremail.lkang0305@163.com> <76c18800.41ee.16e1a553723.Coremail.lkang0305@163.com> From: Luis Machado Message-ID: Date: Wed, 30 Oct 2019 01:46:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 MIME-Version: 1.0 In-Reply-To: <76c18800.41ee.16e1a553723.Coremail.lkang0305@163.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-IsSubscribed: yes X-SW-Source: 2019-10/txt/msg00050.txt.bz2 On 10/29/19 10:43 PM, 刘康 wrote: > Hmmm, I'll switch my gdbserver to a latest version. > > Thank you so much and sorry for boring you with this. Not a problem. The list is here for answering questions like these. Luis > > > At 2019-10-29 20:36:59, "Luis Machado" wrote: >>Hi, >> >> From reading the GDB NEWS file, proper support for gdbserver >>remote/extended-remote fork/vfork event reporting was included in GDB >>7.11, commit 19d9d4efd18bcc633e99cb6a3e39bd9b22ca70ce and others. >> >>I'd give a more recent GDB a try, since GDB 7.6 is mora than 5 years old >>now. >> >>On 10/29/19 7:42 AM, 刘康 wrote: >>> Hi, >>> My gdbserver andarm-linux-androideabi-gdbversion are both 7.6. and my >>> reproduction way is as follow: >>> >>> >>> >>> and my gdbremotescript.gdb is >>> >>> >>> the debug target "usb_upgrade_check" is the ELF of the source code >>> above(just ignore its strange name...it means nothing:-)     ) >>> >>> my target and host is communicating via TCP/IP protocol and my target >>> gdbserver launch parameter is >>> >>> >>> my target's kernel version is 3.10.86 >>> >>> When everything is ready I do "set detach-on-fork off" and "set >>> follow-fork-mode child" at host and execute the continue command. >>> The problem comes: host always has only one inferior which trace parent >>> process, no new inferior will be created and the child process could not >>> be traced in any way. >>> I have also tried version 7.9 and the performance is the same. >>> >>> My kernel and libc works well for syscall like ptrace and waitpid , >>> because I have make sure that the linux_test_for_tracefork() has no >>> problem by adding gdbserver some log. >>> >>> At 2019-10-28 20:26:33, "Luis Machado" wrote: >>>>Do let us know what you see. If it still doesn't work with the most >>>>recent versions, it may be a real bug somewhere (not necessarily in >>>>gdb/gdbserver). >>>> >>>>On 10/28/19 8:12 AM, 刘康 wrote: >>>>> Hi, >>>>> I see, maybe my gdbserver version is too old...I'll compile a latest >>>>> version and try again. >>>>> >>>>> Thank you so much for your help! >>>>> >>>>> >>>>> At 2019-10-24 18:38:46, "Luis Machado" wrote: >>>>>>Hi, >>>>>> >>>>>>I just ran a quick check (foll-fork.exp and follow-vfork.exp tests) on a >>>>>>arm machine and things worked as expected. >>>>>> >>>>>>What version of GDB/kernel are you using? >>>>>> >>>>>>On 10/24/19 2:32 AM, 刘康 wrote: >>>>>>> Hi Luis, >>>>>>> >>>>>>> Yes, I know that gdbserver willcatch PTRACE_EVENT_FORK in >>>>>>> gdb/gdbserver/linux-low.c:handle_extended_wait and get the child >>>>>>> process's pid via PTRACE_GETEVENTMSG. >>>>>>> >>>>>>> I found the way of X86 version gdb to deal with PTRACE_EVENT_FORKwill >>>>>>> set waitstatus toTARGET_WAITKIND_FORKED and add a new inferior .What's >>>>>>> more ,it can trace child/parent process automatically as long as I set >>>>>>> "follow-fork-mode" to "child" or "parent". >>>>>>> >>>>>>> But it seems like gdbserver will not tell PTRACE_EVENT_FORK to thehost >>>>>>> arm-XXX-gdb this event ,as a result , user cannot trace child process or >>>>>>> add a new inferior no matter what value of "detach-on-fork off" and >>>>>>> "follow-fork-mode" I have tried. >>>>>>> >>>>>>> At 2019-10-18 20:27:19, "Luis Machado" wrote: >>>>>>>>Hi, >>>>>>>> >>>>>>>>On 10/17/19 3:19 AM, 刘康 wrote: >>>>>>>>> Dear gdb@sourceware.org >>>>>>>>> >>>>>>>>> >>>>>>>>> I am researching the gdbserver's source code for ARM, what confused me is that it does not support multi-process to debug the target's child process, cause it dose not interesting in PTRACE_EVENT_FORK, I don't know whether it's a bug or it's just a feature by design. >>>>>>>> >>>>>>>>The handling of PTRACE_EVENT_FORK, PTRACE_EVENT_VFORK and >>>>>>>>PTRACE_EVENT_CLONE is in generic linux code. See >>>>>>>>gdb/gdbserver/linux-low.c:handle_extended_wait. >>>>>>>> >>>>>>>>As long as the kernel supports reporting such events via ptrace and we >>>>>>>>are debugging using extended remote mode (not regular remote mode), it >>>>>>>>should work. If it doesn't, then we may have a problem that we should fix. >>>>>>>> >>>>>>>>Does that answer your question? >>>>>>>> >>>>>>>>Luis >>>>>>> >>>>>>> >>>>>>> >>>>> >>>>> >>>>> >>> >>> >>> > > >