gdbserver for arm does not support multi-process debugging

gdbserver for arm does not support multi-process debugging

[刘康]

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.


Appreciate very much for any reply and thank you so much!

Re: gdbserver for arm does not support multi-process debugging

[Luis Machado]

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

Re: gdbserver for arm does not support multi-process debugging

[Luis Machado]

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" <luis.machado@linaro.org> 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
> 
> 
> 

Re:Re: gdbserver for arm does not support multi-process debugging

[刘康]

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" <luis.machado@linaro.org> 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" <luis.machado@linaro.org> 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
>> 
>> 
>> 

Re: gdbserver for arm does not support multi-process debugging

[Luis Machado]

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" <luis.machado@linaro.org> 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" <luis.machado@linaro.org> 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" <luis.machado@linaro.org> 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" <luis.machado@linaro.org> 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
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>> 
>>> 
>>> 
> 
> 
>