From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30678 invoked by alias); 21 Nov 2016 16:27:06 -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 30655 invoked by uid 89); 21 Nov 2016 16:27:05 -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=watch, interest, learn 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; Mon, 21 Nov 2016 16:27:03 +0000 Received: from svr-orw-mbx-03.mgc.mentorg.com ([147.34.90.203]) by relay1.mentorg.com with esmtp id 1c8rQq-00072K-J6 from Luis_Gustavo@mentor.com ; Mon, 21 Nov 2016 08:27:00 -0800 Received: from [172.30.6.207] (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; Mon, 21 Nov 2016 08:26:57 -0800 Subject: Re: [bug?] [patch] target remote and multiprocess+ References: <5832E93B.9060507@marco.de> To: Matthias Pfaller , Reply-To: Luis Machado From: Luis Machado Message-ID: Date: Mon, 21 Nov 2016 16:27: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: <5832E93B.9060507@marco.de> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit X-ClientProxiedBy: svr-orw-mbx-03.mgc.mentorg.com (147.34.90.203) To svr-orw-mbx-03.mgc.mentorg.com (147.34.90.203) X-IsSubscribed: yes X-SW-Source: 2016-11/txt/msg00034.txt.bz2 On 11/21/2016 06:31 AM, Matthias Pfaller wrote: > Hi, > > in order to have per thread watch and break points I resorted to report > "multiprocess+;" and put each thread into its very own "process". But > when I did this, I got the following display: > > (gdb) info inferiors > Num Description Executable > * 1 process 536909700 firmware/firmware.elf > (gdb) info threads > Id Target Id Frame > 1 Thread 536949956.536949956 (gdbstub R 00000000 0) > (running) > 2 Thread 536948708.536948708 (lightshow S 2000fac4 36) > (running) > 3 Thread 536947332.536947332 (dspleds S 2000faf2 33) > (running) > 4 Thread 536945956.536945956 (vtask S 2000fb2a 35) > (running) > 5 Thread 536944580.536944580 (kit S 2000fb92 0) > (running) > 6 Thread 536943204.536943204 (counter S 2000a382 0) > (running) > 7 Thread 536941796.536941796 (ssb 3 S 20011348 0) > (running) > 8 Thread 536940484.536940484 (ssb U S 20010e24 0) > (running) > 9 Thread 536929924.536929924 (ptpd S 004bf68d 1622) > (running) > 10 Thread 536928164.536928164 (swarmbee S 2000e57c 6) > (running) > 11 Thread 536927044.536927044 (telnetd S 2000dae8 0) > (running) > 12 Thread 536925956.536925956 (tftpds S 2000d2f4 0) > (running) > 13 Thread 536924964.536924964 (tftpds S 2000d2f0 0) > (running) > 14 Thread 536924484.536924484 (tftpd S 2000d109 0) > (running) > 15 Thread 536923812.536923812 (psuctrl S 2000d0cc 96) > (running) > 16 Thread 536922692.536922692 (pmnet S 20004828 998) > (running) > 17 Thread 536920868.536920868 (tcpip_thread S 2000c311 65) > (running) > 18 Thread 536920228.536920228 (valves S 00484dd5 45) > (running) > 19 Thread 536916932.536916932 (ssb_upd S 00000000 48) > (running) > 20 Thread 536916196.536916196 (ssb_link S 004981a1 0) > (running) > 21 Thread 536915748.536915748 (power S 00000000 1) > (running) > 22 Thread 536915140.536915140 (alive S 00000000 5) > (running) > 23 Thread 536914596.536914596 (slow S 00000000 1) > (running) > 24 Thread 536914244.536914244 (wdog S 00000000 22) > (running) > 25 Thread 536913124.536913124 (dsp R 00000000 0) > (running) > 26 Thread 536911044.536911044 (f83console S 2000e5c8 0) > (running) > * 27 Thread 536909700.536909700 (idle R 00000000 0) > (running) > (gdb) > > I don't think this is the way this should work. I did a simple patch to > remote.c and inferior.c. Now I get (don't mind the different lwp/pid > format): > (gdb) info inferiors > Num Description Executable > 1 200134c4 firmware.elf > 2 20012fe4 firmware.elf > 3 20012a84 firmware.elf > 4 20012524 firmware.elf > 5 20011fc4 firmware.elf > 6 20011a64 firmware.elf > 7 200114e4 firmware.elf > 8 20010fc4 firmware.elf > 9 2000e684 firmware.elf > 10 2000dfa4 firmware.elf > 11 2000db44 firmware.elf > 12 2000d704 firmware.elf > 13 2000d324 firmware.elf > 14 2000d144 firmware.elf > 15 2000cea4 firmware.elf > 16 2000ca44 firmware.elf > 17 2000c324 firmware.elf > 18 2000c0a4 firmware.elf > 19 2000b3c4 firmware.elf > 20 2000b0e4 firmware.elf > 21 2000af24 firmware.elf > 22 2000acc4 firmware.elf > 23 2000aaa4 firmware.elf > 24 2000a944 firmware.elf > 25 2000a4e4 firmware.elf > 26 20009cc4 firmware.elf > * 27 20009784 firmware.elf > (gdb) info threads > Id Target Id Frame > 1.1 200134c4 (gdbstub R 00000000 0) (running) > 2.1 20012fe4 (lightshow S 2000fac4 29) (running) > 3.1 20012a84 (dspleds S 2000faf2 28) (running) > 4.1 20012524 (vtask S 2000fb2a 50) (running) > 5.1 20011fc4 (kit S 2000fb92 0) (running) > 6.1 20011a64 (counter S 2000a382 0) (running) > 7.1 200114e4 (ssb 3 S 20011348 0) (running) > 8.1 20010fc4 (ssb U S 20010e24 0) (running) > 9.1 2000e684 (ptpd S 004bf68d 483) (running) > 10.1 2000dfa4 (swarmbee S 2000e57c 9) (running) > 11.1 2000db44 (telnetd S 2000dae8 0) (running) > 12.1 2000d704 (tftpds S 2000d2f4 0) (running) > 13.1 2000d324 (tftpds S 2000d2f0 0) (running) > 14.1 2000d144 (tftpd S 2000d109 0) (running) > 15.1 2000cea4 (psuctrl S 2000d0cc 96) (running) > 16.1 2000ca44 (pmnet S 20004828 999) (running) > 17.1 2000c324 (tcpip_thread S 2000c311 12) (running) > 18.1 2000c0a4 (valves S 00484dd5 48) (running) > 19.1 2000b3c4 (ssb_upd S 00000000 11) (running) > 20.1 2000b0e4 (ssb_link S 004981a1 0) (running) > 21.1 2000af24 (power S 00000000 1) (running) > 22.1 2000acc4 (alive S 00000000 4) (running) > 23.1 2000aaa4 (slow S 00000000 4) (running) > 24.1 2000a944 (wdog S 00000000 29) (running) > 25.1 2000a4e4 (dsp S 0048b401 73) (running) > 26.1 20009cc4 (f83console S 2000e5c8 0) (running) > * 27.1 20009784 (idle R 00000000 0) (running) > (gdb) > > --- ../orig/gdb/inferior.c > +++ ./gdb/inferior.c > @@ -320,13 +320,27 @@ > void > discard_all_inferiors (void) > { > - struct inferior *inf; > + struct inferior *inf, *infnext; > > - for (inf = inferior_list; inf; inf = inf->next) > + for (inf = inferior_list; inf; inf = infnext) > { > - if (inf->pid != 0) > - exit_inferior_silent (inf->pid); > + infnext = inf->next; > + > + if (inf->num == 1) > + { > + if (inf->pid != 0) > + exit_inferior_1 (inf, 1); > + } > + else > + delete_inferior (inf); > } > + > + inferior_ptid = null_ptid; > + inferior_list->pid = 0; > + set_current_inferior (inferior_list); > + switch_to_thread (null_ptid); > + > + highest_inferior_num = inferior_list->num; > } > > struct inferior * > --- ../orig/gdb/remote.c > +++ ./gdb/remote.c > @@ -1789,8 +1789,23 @@ > /* In the traditional debugging scenario, there's a 1-1 match > between program/address spaces. We simply bind the inferior > to the program space's address space. */ > - inf = current_inferior (); > - inferior_appeared (inf, pid); > + > + inf = find_inferior_id (pid); > + if (inf == NULL) > + { > + if (current_inferior () ->pid == 0) > + { > + inf = current_inferior (); > + inferior_appeared (inf, pid); > + } > + else > + { > + inf = add_inferior (pid); > + inf->aspace = current_inferior () ->aspace; > + inf->pspace = current_program_space; > + inf->gdbarch = current_inferior () ->gdbarch; > + } > + } > } > > inf->attach_flag = attached; > @@ -1801,6 +1816,10 @@ > if (try_open_exec && get_exec_file (0) == NULL) > exec_file_locate_attach (pid, 0, 1); > > + set_current_inferior (inf); > + > + inferior_ptid = pid_to_ptid (pid); > + > return inf; > } > > @@ -1902,6 +1921,9 @@ > > /* This is really a new thread. Add it. */ > remote_add_thread (currthread, running, executing); > + if (ptid_is_pid (inferior_ptid) > + && pid == ptid_get_pid (inferior_ptid)) > + inferior_ptid = currthread; > > /* If we found a new inferior, let the common code do whatever > it needs to with it (e.g., read shared libraries, insert > > Can anybody tell me how this is used at the moment and weather my patch > is interfering with the current usage? > > I have done a second patch that limits stop_all_threads and > restart_threads to the tasks belonging to the stopped inferior because I > cannot stop all threads while debugging. Is there any interest in this? > > regards, Matthias > Sorry, i don't think this patch is acceptable as is. GDB would need to learn how to handle thread-specific break/watch requests. That will take a bit more work though. The above patch does interfere with the way GDB handles things. I believe the testsuite will show regressions if you run it with this patch applied.