This is the mail archive of the gdb@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]