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

Luis Machado lgustavo@codesourcery.com
Mon Nov 21 16:27:00 GMT 2016


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.



More information about the Gdb mailing list