From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 77584 invoked by alias); 23 Nov 2016 15:45:37 -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 77572 invoked by uid 89); 23 Nov 2016 15:45:36 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy= X-HELO: relay1.mentorg.com Received: from relay1.mentorg.com (HELO relay1.mentorg.com) (192.94.38.131) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 23 Nov 2016 15:45:34 +0000 Received: from svr-orw-mbx-03.mgc.mentorg.com ([147.34.90.203]) by relay1.mentorg.com with esmtp id 1c9Zjn-0001HK-FM from Luis_Gustavo@mentor.com ; Wed, 23 Nov 2016 07:45:31 -0800 Received: from [172.30.6.103] (147.34.91.1) by svr-orw-mbx-03.mgc.mentorg.com (147.34.90.203) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 23 Nov 2016 07:45:28 -0800 Reply-To: Luis Machado Subject: Re: [bug?] [patch] target remote and multiprocess+ References: <5832E93B.9060507@marco.de> <58355990.3000002@marco.de> To: Matthias Pfaller , GDB From: Luis Machado Message-ID: Date: Wed, 23 Nov 2016 15:45:00 -0000 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: <58355990.3000002@marco.de> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit X-ClientProxiedBy: svr-orw-mbx-01.mgc.mentorg.com (147.34.90.201) To svr-orw-mbx-03.mgc.mentorg.com (147.34.90.203) X-IsSubscribed: yes X-SW-Source: 2016-11/txt/msg00040.txt.bz2 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\n\n id="p3dcf.3dcf" core="1" name="xterm"/>\n\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\n\n id="p3dcf.3dcf" core="1" name="xterm"/>\n\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 Installation error: > gdb.execute_unwinders function is missing: > > Thread 1.1 "xterm" stopped. > 0x00007ffff7ddac80 in ?? () > Python Exception 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 'exceptions.NameError'> Installation error: gdb.execute_unwinders > function is missing: > 0x00007ffff7ddac80 in ?? () > * 2.1 Thread 15823.15823 "xterm" Python Exception '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"