Re: [bug?] [patch] target remote and multiprocess+
Luis Machado <[email protected]>
| Newsgroups | gmane.comp.gdb.devel |
|---|---|
| Message-ID | <[email protected]> |
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.