Re: [bug?] [patch] target remote and multiprocess+

On 11/28/2016 03:23 AM, Matthias Pfaller wrote:
> On 11/23/2016 04:45 PM, Luis Machado wrote:
>> Hi,
>>
>> On 11/23/2016 02:55 AM, Matthias Pfaller wrote:
>>> To make sure I'm not totally wrong I did run an (unpatched) gdbserver
>>> (7.11.1) -multi on my host machine. Then I connected with
>>> extended-remote and created two inferiors. After a disconnect and a
>>> reconnect gdbserver responds with the following inferior/thread list:
>>>
>>> l<threads>\n<thread id="p29ae.29ae" core="3" name="xterm"/>\n<thread
>>> id="p3dcf.3dcf" core="1" name="xterm"/>\n</threads>\n
>>>
>>> But doing a "info inferiors" will show:
>>> (gdb) info inferiors
>>>   Num  Description       Executable
>>> * 1    process 15823     /usr/uti/xterm
>>>
>>> and info threads:
>>> (gdb) info threads
>>> Sending packet: $qXfer:threads:read::0,fff#03...Packet received:
>>> l<threads>\n<thread id="p29ae.29ae" core="3" name="xterm"/>\n<thread
>>> id="p3dcf.3dcf" core="1" name="xterm"/>\n</threads>\n
>>>   Id   Target Id         Frame
>>>   1    Thread 10670.10670 "xterm"
>>> ../../gdb/thread.c:1447: internal-error: switch_to_thread: Assertion
>>> `inf != NULL' failed.
>>> A problem internal to GDB has been detected,
>>> further debugging may prove unreliable.
>>> Quit this debugging session? (y or n)
>>>
>>> (note that this is the host system's gdb 7.11.1)
>>> So attaching to a target with multiple running inferiors just doesn't
>>> work at the moment.
>>>
>>> Now I tried with gdb-7.12 and my patches applied:
>>>
>>> (gdb) set non-stop on
>>> (gdb) target remote localhost:29979
>>> Remote debugging using localhost:29979
>>> Reading /usr/uti/xterm from remote target...
>>> warning: File transfers from remote targets can be slow. Use "set
>>> sysroot" to access files locally instead.
>>> Reading /usr/uti/xterm from remote target...
>>> Reading symbols from target:/usr/uti/xterm...(no debugging symbols
>>> found)...done.
>>> Python Exception <type 'exceptions.NameError'> Installation error:
>>> gdb.execute_unwinders function is missing:
>>>
>>> Thread 1.1 "xterm" stopped.
>>> 0x00007ffff7ddac80 in ?? ()
>>> Python Exception <type 'exceptions.NameError'> Installation error:
>>> gdb.execute_unwinders function is missing:
>>>
>>> Thread 2.1 "xterm" stopped.
>>> 0x00007ffff7ddac80 in ?? ()
>>> (gdb) info threads
>>>   Id   Target Id         Frame
>>>   1.1  Thread 10670.10670 "xterm" Python Exception <type
>>> 'exceptions.NameError'> Installation error: gdb.execute_unwinders
>>> function is missing:
>>> 0x00007ffff7ddac80 in ?? ()
>>> * 2.1  Thread 15823.15823 "xterm" Python Exception <type
>>> 'exceptions.NameError'> Installation error: gdb.execute_unwinders
>>> function is missing:
>>> 0x00007ffff7ddac80 in ?? ()
>>> (gdb) info inferiors
>>>   Num  Description       Executable
>>>   1    process 10670     target:/usr/uti/xterm
>>> * 2    process 15823     target:/usr/uti/xterm
>>>
>>> So I think this is at least not worse than what gdb was doing before...
>>> Is there a chance to get this patch into gdb?
>>>
>>> Matthias
>>>
>>
>> I think i misunderstood your initial explanation. So the patch in
>> questions attempts to fix the internal error plus the fact that GDB
>> doesn't show more than one inferior when connecting to a gdbserver that
>> is controlling multiple inferiors?
>>
>> If so, indeed it is a bug and i still see it on master GDB. I'd send the
>> patch to gdb-patches so we can properly review it.
>>
>> Also, did you run the gdb testsuite to make sure your patch did not
>> introduce regressions comparing against the unpatch gdb testsuite run?
>>
>> You can run the testsuite like this:
>>
>> make check-gdb (top-level) or make-gdb
>>
>> You should also run the testsuite against gdbserver like this:
>>
>> make check-gdb RUNTESTFLAGS="--target_board native-gdbserver"
>
> A gdb-7.12 built with the attached patch gives the same FAIL lines for
>   make check
> and
>   make check-gdb RUNTESTFLAGS="--target_board native-gdbserver"
> as a gdb-7.12 built without my patch.
>
> The patch does:
> * make "multiprocess+;" work with "target remote"
> * stop inferiors only for the event thread when a break or watch point
> is hit
> * stop new inferiors only when global break or watch points are in place
>
> This makes it possible to debug an embedded target where gdbserver is
> running as native thread on the target. The target has to report the
> threadlist as an inferiorlist with one thread per inferior. That way one
> can context switch break and watch points and halt only the thread to be
> debugged.
>
> regards, Matthias
>

Great. Could you please send this patch to [email protected] 
then? It is the proper place for reviews. And please mention it has been 
regression-tested.