* Don't try to report resumed thread it the thread list is empty.
@ 2008-07-05 17:58 Vladimir Prus
2008-07-09 10:31 ` Pedro Alves
0 siblings, 1 reply; 5+ messages in thread
From: Vladimir Prus @ 2008-07-05 17:58 UTC (permalink / raw)
To: gdb-patches
[-- Attachment #1: Type: text/plain, Size: 158 bytes --]
I've checked in the below to make GDB not assert in MI mode on
targets where single-threaded programs have zero threads in the
GDB thread table.
- Volodya
[-- Attachment #2: on_resume.diff --]
[-- Type: text/x-diff, Size: 1332 bytes --]
Index: gdb/ChangeLog
===================================================================
RCS file: /cvs/src/src/gdb/ChangeLog,v
retrieving revision 1.9517
diff -u -p -r1.9517 ChangeLog
--- gdb/ChangeLog 5 Jul 2008 13:48:20 -0000 1.9517
+++ gdb/ChangeLog 5 Jul 2008 17:56:47 -0000
@@ -1,3 +1,8 @@
+2008-07-05 Vladimir Prus <vladimir@codesourcery.com>
+
+ * mi/mi-interp.c (mi_on_resume): Don't try to report
+ resumed thread it the thread list is empty.
+
2008-07-05 Pierre Muller <muller@ics.u-strasbg.fr>
* cli/cli-decode.c (add_setshow_optional_filename_cmd): Set
Index: gdb/mi/mi-interp.c
===================================================================
RCS file: /cvs/src/src/gdb/mi/mi-interp.c,v
retrieving revision 1.34
diff -u -p -r1.34 mi-interp.c
--- gdb/mi/mi-interp.c 25 Jun 2008 15:15:42 -0000 1.34
+++ gdb/mi/mi-interp.c 5 Jul 2008 17:56:47 -0000
@@ -338,6 +338,12 @@ mi_on_resume (ptid_t ptid)
if (PIDGET (ptid) == -1)
fprintf_unfiltered (raw_stdout, "*running,thread-id=\"all\"\n");
+ else if (thread_count () == 0)
+ {
+ /* This is a target where for single-threaded programs the thread
+ table has zero threads. Don't print any thread-id field. */
+ fprintf_unfiltered (raw_stdout, "*running\n");
+ }
else
{
struct thread_info *ti = find_thread_pid (ptid);
^ permalink raw reply [flat|nested] 5+ messages in thread* Re: Don't try to report resumed thread it the thread list is empty. 2008-07-05 17:58 Don't try to report resumed thread it the thread list is empty Vladimir Prus @ 2008-07-09 10:31 ` Pedro Alves 2008-07-09 12:04 ` Vladimir Prus 0 siblings, 1 reply; 5+ messages in thread From: Pedro Alves @ 2008-07-09 10:31 UTC (permalink / raw) To: gdb-patches; +Cc: Vladimir Prus A Saturday 05 July 2008 18:58:29, Vladimir Prus wrote: > I've checked in the below to make GDB not assert in MI mode on > targets where single-threaded programs have zero threads in the > GDB thread table. > FYI, running the MI testsuite on a target that doesn't register the main thread in ST programs, has failures that look like: -exec-continue ^running *running (gdb) *stopped,reason="breakpoint-hit",disp="keep",bkptno="2",thread-id="0",frame={addr="0x000087e0",func="do_special_tests",args=[],file="../../../src/gdb/testsuite/gdb.mi/var-cmd.c",fullname="/home/pedro/gdb/monitor_always_a_thread/src/gdb/testsuite/gdb.mi/var-cmd.c",line="319"} (gdb) FAIL: gdb.mi/mi2-var-display.exp: continue to do_special_tests (failed to resume) I believe the issue is that in lib/mi-support.exp, *running matching assumes there is -thread-id field -re "220\\^running\[\r\n\]+\\*running,thread-id=\"\[^\"\]+\"\r\n$mi_gdb_prompt$" {} I notice that there are other places that are outputing -thread-id="0", e.g.: *stopped,reason="breakpoint-hit",disp="keep",bkptno="2",thread-id="0",frame={addr="0x000087e0",func="do_special_tests",args=[],file="../../../src/gdb/testsuite/gdb.mi/var-cmd.c",fullname="/home/pedro/gdb/monitor_always_a_thread/src/gdb/testsuite/gdb.mi/var-cmd.c",line="319"} (gdb) So maybe we should make this consistent, and output -thread-id="0" in *running as well? -- Pedro Alves ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Don't try to report resumed thread it the thread list is empty. 2008-07-09 10:31 ` Pedro Alves @ 2008-07-09 12:04 ` Vladimir Prus 2008-07-09 12:52 ` Pedro Alves 0 siblings, 1 reply; 5+ messages in thread From: Vladimir Prus @ 2008-07-09 12:04 UTC (permalink / raw) To: Pedro Alves; +Cc: gdb-patches On Wednesday 09 July 2008 14:31:21 Pedro Alves wrote: > A Saturday 05 July 2008 18:58:29, Vladimir Prus wrote: > > I've checked in the below to make GDB not assert in MI mode on > > targets where single-threaded programs have zero threads in the > > GDB thread table. > > > > FYI, running the MI testsuite on a target that doesn't register > the main thread in ST programs, For the record, which target did you test on? > has failures that look like: > > -exec-continue > ^running > *running > (gdb) > *stopped,reason="breakpoint-hit",disp="keep",bkptno="2",thread-id="0",frame={addr="0x000087e0",func="do_special_tests",args=[],file="../../../src/gdb/testsuite/gdb.mi/var-cmd.c",fullname="/home/pedro/gdb/monitor_always_a_thread/src/gdb/testsuite/gdb.mi/var-cmd.c",line="319"} > (gdb) > FAIL: gdb.mi/mi2-var-display.exp: continue to do_special_tests (failed to > resume) > > I believe the issue is that in lib/mi-support.exp, *running matching assumes > there is -thread-id field > > -re "220\\^running\[\r\n\]+\\*running,thread-id=\"\[^\"\]+\"\r\n$mi_gdb_prompt$" > {} > > I notice that there are other places that are outputing -thread-id="0", e.g.: > > *stopped,reason="breakpoint-hit",disp="keep",bkptno="2",thread-id="0",frame={addr="0x000087e0",func="do_special_tests",args=[],file="../../../src/gdb/testsuite/gdb.mi/var-cmd.c",fullname="/home/pedro/gdb/monitor_always_a_thread/src/gdb/testsuite/gdb.mi/var-cmd.c",line="319"} > (gdb) > > So maybe we should make this consistent, and output -thread-id="0" > in *running as well? I'm not sure which way we want to make it consistent. Outputiing "thread-id" with a "I don't exist" value of thread id seems a little bit distasteful. I guess I can modify regexp to make thread-id optional. - Volodya ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Don't try to report resumed thread it the thread list is empty. 2008-07-09 12:04 ` Vladimir Prus @ 2008-07-09 12:52 ` Pedro Alves 2008-07-09 13:04 ` Pedro Alves 0 siblings, 1 reply; 5+ messages in thread From: Pedro Alves @ 2008-07-09 12:52 UTC (permalink / raw) To: Vladimir Prus; +Cc: gdb-patches A Wednesday 09 July 2008 13:04:11, Vladimir Prus wrote: > On Wednesday 09 July 2008 14:31:21 Pedro Alves wrote: > > A Saturday 05 July 2008 18:58:29, Vladimir Prus wrote: > > > I've checked in the below to make GDB not assert in MI mode on > > > targets where single-threaded programs have zero threads in the > > > GDB thread table. > > > > FYI, running the MI testsuite on a target that doesn't register > > the main thread in ST programs, > > For the record, which target did you test on? arm-elf with target sim. I've checked in the patch to make it always have a thread, but it's just a matter of commenting out the add_thread_silent call to get the old behaviour. > I'm not sure which way we want to make it consistent. Outputiing > "thread-id" with a "I don't exist" value of thread id seems a little bit > distasteful. I guess I can modify regexp to make thread-id optional. I meant either output -thread-id="0" everywhere, or don't output -thread=id at all, nowhere. -- Pedro Alves ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Don't try to report resumed thread it the thread list is empty. 2008-07-09 12:52 ` Pedro Alves @ 2008-07-09 13:04 ` Pedro Alves 0 siblings, 0 replies; 5+ messages in thread From: Pedro Alves @ 2008-07-09 13:04 UTC (permalink / raw) To: gdb-patches; +Cc: Vladimir Prus A Wednesday 09 July 2008 13:52:28, Pedro Alves wrote: > A Wednesday 09 July 2008 13:04:11, Vladimir Prus wrote: > > I'm not sure which way we want to make it consistent. Outputiing > > "thread-id" with a "I don't exist" value of thread id seems a little bit > > distasteful. I guess I can modify regexp to make thread-id optional. > > I meant either output -thread-id="0" everywhere, or don't output -thread=id > at all, nowhere. To be clear, I don't care that much about this inconsistency, what I really want to have all targets register at least a thread, so modifying the regexp is also fine with me, FWIW. Although I thought that changing the code in this case would be a less invasive change, than relaxing the testsuite. -- Pedro Alves ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2008-07-09 13:04 UTC | newest] Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2008-07-05 17:58 Don't try to report resumed thread it the thread list is empty Vladimir Prus 2008-07-09 10:31 ` Pedro Alves 2008-07-09 12:04 ` Vladimir Prus 2008-07-09 12:52 ` Pedro Alves 2008-07-09 13:04 ` Pedro Alves
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox