* [bug?] [patch] target remote and multiprocess+
@ 2016-11-21 12:32 Matthias Pfaller
2016-11-21 16:27 ` Luis Machado
0 siblings, 1 reply; 7+ messages in thread
From: Matthias Pfaller @ 2016-11-21 12:32 UTC (permalink / raw)
To: gdb
[-- 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 --]
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [bug?] [patch] target remote and multiprocess+
2016-11-21 12:32 [bug?] [patch] target remote and multiprocess+ Matthias Pfaller
@ 2016-11-21 16:27 ` Luis Machado
2016-11-22 7:17 ` Matthias Pfaller
2016-11-23 8:55 ` Matthias Pfaller
0 siblings, 2 replies; 7+ messages in thread
From: Luis Machado @ 2016-11-21 16:27 UTC (permalink / raw)
To: Matthias Pfaller, gdb
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.
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [bug?] [patch] target remote and multiprocess+
2016-11-21 16:27 ` Luis Machado
@ 2016-11-22 7:17 ` Matthias Pfaller
2016-11-23 8:55 ` Matthias Pfaller
1 sibling, 0 replies; 7+ messages in thread
From: Matthias Pfaller @ 2016-11-22 7:17 UTC (permalink / raw)
To: Luis Machado, gdb
[-- 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 --]
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [bug?] [patch] target remote and multiprocess+
2016-11-21 16:27 ` Luis Machado
2016-11-22 7:17 ` Matthias Pfaller
@ 2016-11-23 8:55 ` Matthias Pfaller
2016-11-23 15:45 ` Luis Machado
1 sibling, 1 reply; 7+ messages in thread
From: Matthias Pfaller @ 2016-11-23 8:55 UTC (permalink / raw)
To: Luis Machado, GDB
[-- 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 --]
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [bug?] [patch] target remote and multiprocess+
2016-11-23 8:55 ` Matthias Pfaller
@ 2016-11-23 15:45 ` Luis Machado
2016-11-28 9:24 ` Matthias Pfaller
0 siblings, 1 reply; 7+ messages in thread
From: Luis Machado @ 2016-11-23 15:45 UTC (permalink / raw)
To: Matthias Pfaller, GDB
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"
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [bug?] [patch] target remote and multiprocess+
2016-11-23 15:45 ` Luis Machado
@ 2016-11-28 9:24 ` Matthias Pfaller
2016-11-28 16:07 ` Luis Machado
0 siblings, 1 reply; 7+ messages in thread
From: Matthias Pfaller @ 2016-11-28 9:24 UTC (permalink / raw)
To: Luis Machado, GDB
[-- 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 --]
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [bug?] [patch] target remote and multiprocess+
2016-11-28 9:24 ` Matthias Pfaller
@ 2016-11-28 16:07 ` Luis Machado
0 siblings, 0 replies; 7+ messages in thread
From: Luis Machado @ 2016-11-28 16:07 UTC (permalink / raw)
To: Matthias Pfaller, GDB
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.
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2016-11-28 16:07 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2016-11-21 12:32 [bug?] [patch] target remote and multiprocess+ Matthias Pfaller
2016-11-21 16:27 ` Luis Machado
2016-11-22 7:17 ` Matthias Pfaller
2016-11-23 8:55 ` Matthias Pfaller
2016-11-23 15:45 ` Luis Machado
2016-11-28 9:24 ` Matthias Pfaller
2016-11-28 16:07 ` Luis Machado
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox