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

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

[Matthias Pfaller]

[-- Attachment #1: Type: text/plain, Size: 8479 bytes --]

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
-- 
Matthias Pfaller                          Software Entwicklung
marco Systemanalyse und Entwicklung GmbH  Tel   +49 8131 5161 41
Hans-Böckler-Str. 2, D 85221 Dachau       Fax   +49 8131 5161 66
http://www.marco.de/                      Email leo@marco.de
Geschäftsführer Martin Reuter             HRB 171775 Amtsgericht München


[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 4349 bytes --]

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

[Luis Machado]

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.

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

[Matthias Pfaller]

[-- Attachment #1: Type: text/plain, Size: 3543 bytes --]

On 11/21/2016 05:26 PM, Luis Machado wrote:
> 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)
>> ..
>> (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
>> ...
>> (gdb) info threads
>>   Id   Target Id         Frame
>>   1.1  200134c4 (gdbstub      R    00000000       0) (running)
>>   2.1  20012fe4 (lightshow    S    2000fac4      29) (running)
>> ...
>> * 27.1 20009784 (idle         R    00000000       0) (running)
>> (gdb)
>> [patch omitted]
>> 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.

Actually my patch should not interfere at all (I hope ...).

At the moment gdb inserts global watch and break points into all
inferiors that get debugged. Only when gdbarch_has_global_breakpoints
returns true the breakpoint is inserted into just one inferior.

In all other cases the correct inferior has to be selected before
planting the break point. When I finally understood this, I made my
target return "multiprocess+;". When I return the thread list to gdb I
place every thread into its very own process. That way gdb automatically
does the correct thing when I place a thread specific break point (i.e.
selecting the correct general process before setting the break point).

But when I reported the thread list gdb would not construct a correct
inferior list (with remote.c). My patch tries to fix this. Once all this
might have worked for the only arch that returns
gdbarch_has_global_breakpoints as true (dicos). But I just can't see how
this would work in the normal case.

The other thing I tried to fix are gdb crashes on disconnect/reconnect
with a multiprocess+ target.

regards, Matthias
-- 
Matthias Pfaller                          Software Entwicklung
marco Systemanalyse und Entwicklung GmbH  Tel   +49 8131 5161 41
Hans-Böckler-Str. 2, D 85221 Dachau       Fax   +49 8131 5161 66
http://www.marco.de/                      Email leo@marco.de
Geschäftsführer Martin Reuter             HRB 171775 Amtsgericht München


[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 4349 bytes --]

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

[Matthias Pfaller]

[-- Attachment #1: Type: text/plain, Size: 3023 bytes --]

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
-- 
Matthias Pfaller                          Software Entwicklung
marco Systemanalyse und Entwicklung GmbH  Tel   +49 8131 5161 41
Hans-Böckler-Str. 2, D 85221 Dachau       Fax   +49 8131 5161 66
http://www.marco.de/                      Email leo@marco.de
Geschäftsführer Martin Reuter             HRB 171775 Amtsgericht München


[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 4349 bytes --]

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

[Luis Machado]

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"

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

[Matthias Pfaller]

[-- Attachment #1.1: Type: text/plain, Size: 4845 bytes --]

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
-- 
Matthias Pfaller                          Software Entwicklung
marco Systemanalyse und Entwicklung GmbH  Tel   +49 8131 5161 41
Hans-Böckler-Str. 2, D 85221 Dachau       Fax   +49 8131 5161 66
http://www.marco.de/                      Email leo@marco.de
Geschäftsführer Martin Reuter             HRB 171775 Amtsgericht München

[-- Attachment #1.2: P.txt --]
[-- Type: text/plain, Size: 6662 bytes --]

--- ../orig/gdb/breakpoint.c
+++ ./gdb/breakpoint.c
--- ../orig/gdb/infcmd.c
+++ ./gdb/infcmd.c
@@ -2741,7 +2741,7 @@
 	  struct thread_info *lowest = inferior_thread ();
 	  int pid = current_inferior ()->pid;
 
-	  stop_all_threads ();
+	  stop_all_threads (inferior);
 
 	  /* It's not defined which thread will report the attach
 	     stop.  For consistency, always select the thread with
@@ -2920,6 +2920,28 @@
   attach_post_wait (args, from_tty, mode);
 }
 
+/* Helper function for any_global_breakpoint.  If B is a global
+   break or catch point, return 1 (which will make
+   'breakpoint_find_if' return).  Otherwise, return 0.  */
+
+static int
+any_global_breakpoint_1 (struct breakpoint *b,
+			   void *data)
+{
+  if (b->enable_state == bp_enabled && b->thread == -1)
+    return 1;
+  else
+    return 0;
+}
+
+static int
+any_global_breakpoint (void)
+{
+  struct breakpoint *b = breakpoint_find_if (any_global_breakpoint_1, NULL);
+
+  return b != NULL;
+}
+
 /* We had just found out that the target was already attached to an
    inferior.  PTID points at a thread of this new inferior, that is
    the most likely to be stopped right now, but not necessarily so.
@@ -2948,7 +2970,9 @@
   /* When we "notice" a new inferior we need to do all the things we
      would normally do if we had just attached to it.  */
 
-  if (is_executing (inferior_ptid))
+  if (!leave_running &&
+      any_global_breakpoint () &&
+      is_executing (inferior_ptid))
     {
       struct attach_command_continuation_args *a;
       struct inferior *inferior = current_inferior ();
--- ../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/infrun.c
+++ ./gdb/infrun.c
@@ -2584,7 +2584,7 @@
 	  /* Fallback to stepping over the breakpoint in-line.  */
 
 	  if (target_is_non_stop_p ())
-	    stop_all_threads ();
+	    stop_all_threads (tp->inf);
 
 	  set_step_over_info (get_regcache_aspace (regcache),
 			      regcache_read_pc (regcache), 0, tp->global_num);
@@ -4496,7 +4496,7 @@
 /* See infrun.h.  */
 
 void
-stop_all_threads (void)
+stop_all_threads (struct inferior *inferior)
 {
   /* We may need multiple passes to discover all threads.  */
   int pass;
@@ -4509,6 +4509,11 @@
   if (debug_infrun)
     fprintf_unfiltered (gdb_stdlog, "infrun: stop_all_threads\n");
 
+  /* With global break points we have always to
+     stop all threads of all inferiors.  */
+  if (gdbarch_has_global_breakpoints (target_gdbarch ()))
+    inferior = NULL;
+
   entry_ptid = inferior_ptid;
   old_chain = make_cleanup (switch_to_thread_cleanup, &entry_ptid);
 
@@ -4539,6 +4544,8 @@
 	     to tell the target to stop.  */
 	  ALL_NON_EXITED_THREADS (t)
 	    {
+	      if (inferior != NULL && inferior != t->inf)
+	      	continue;
 	      if (t->executing)
 		{
 		  /* If already stopping, don't request a stop again.
@@ -5442,7 +5449,7 @@
 
   ALL_NON_EXITED_THREADS (tp)
     {
-      if (tp == event_thread)
+      if (tp == event_thread || tp->inf != event_thread->inf)
 	{
 	  if (debug_infrun)
 	    fprintf_unfiltered (gdb_stdlog,
@@ -7705,7 +7712,7 @@
   /* If all-stop, but the target is always in non-stop mode, stop all
      threads now that we're presenting the stop to the user.  */
   if (!non_stop && target_is_non_stop_p ())
-    stop_all_threads ();
+    stop_all_threads (NULL);
 }
 
 /* Like keep_going, but passes the signal to the inferior, even if the
@@ -7821,7 +7828,7 @@
 	 we're about to step over, otherwise other threads could miss
 	 it.  */
       if (step_over_info_valid_p () && target_is_non_stop_p ())
-	stop_all_threads ();
+	stop_all_threads (ecs->event_thread->inf);
 
       /* Stop stepping if inserting breakpoints fails.  */
       TRY
--- ../orig/gdb/infrun.h
+++ ./gdb/infrun.h
@@ -110,8 +110,12 @@
 extern void set_last_target_status (ptid_t ptid,
 				    struct target_waitstatus status);
 
-/* Stop all threads.  Only returns after everything is halted.  */
-extern void stop_all_threads (void);
+/* Stop all threads belonging to inf.
+   When called with inf == NULL, stop all threads of all inferiors.
+   With gdbarch_has_global_breakpoints () is true, always stop all
+   threads of all inferiors.
+   Only returns after everything is halted.  */
+extern void stop_all_threads (struct inferior *inf);
 
 extern void prepare_for_detach (void);
 
--- ../orig/gdb/remote.c
+++ ./gdb/remote.c
@@ -1789,8 +1789,24 @@
       /* 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;
+	      copy_inferior_target_desc_info(inf, current_inferior ());
+	    }
+        }
     }
 
   inf->attach_flag = attached;
@@ -1801,6 +1817,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 +1922,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
@@ -3937,7 +3960,7 @@
      the inferiors.  */
   if (!non_stop)
     {
-      stop_all_threads ();
+      stop_all_threads (NULL);
 
       /* If all threads of an inferior were already stopped, we
 	 haven't setup the inferior yet.  */

[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 4349 bytes --]

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

[Luis Machado]

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 gdb-patches@sourceware.org 
then? It is the proper place for reviews. And please mention it has been 
regression-tested.