From: "J. Johnston" <jjohnstn@redhat.com>
To: Joel Brobecker <brobecker@gnat.com>
Cc: gdb-patches@sources.redhat.com
Subject: Re: RFA: fix for thread events in thread-db.c
Date: Wed, 04 Jun 2003 23:39:00 -0000 [thread overview]
Message-ID: <3EDE8335.5060708@redhat.com> (raw)
In-Reply-To: <20030604215811.GA3088@gnat.com>
Joel Brobecker wrote:
>>Ok to commit?
>>
>>-- Jeff J.
>>
>>2003-04-23 Jeff Johnston <jjohnstn@redhat.com>
>>
>> * thread-db.c (check_event): For create/death event breakpoints,
>> loop through all messages to ensure that we read the message
>> corresponding to the breakpoint we are at.
>
>
> Jeff, this patch has been approved but there is something I don't get.
> Is the loop variable really necessary? It doesn't seem to ever be
> changed except when you set it right before looping. And the exit from
> the "do ... while" loop seems to be done via a "return".
>
> Thanks.
>
I made it a loop so one can turn on and off the looping externally.
This makes sense if events other than the TD_CREATE event are supported.
For such events, you can use the other libthread_db "get message" interface which allows
you to specify the thread you are interested in and then there is no reason
to loop. I have, for example, made this work for the TD_DEATH event.
The comment explains this; i.e. the loop is not always necessary.
I could have just as easily made it a for (;;) loop but this is functionally
equivalent and makes it sort of obvious how to change it in the future.
>
>>Index: thread-db.c
>>===================================================================
>>RCS file: /cvs/src/src/gdb/thread-db.c,v
>>retrieving revision 1.30
>>diff -u -r1.30 thread-db.c
>>--- thread-db.c 17 Apr 2003 17:30:02 -0000 1.30
>>+++ thread-db.c 23 Apr 2003 19:37:47 -0000
>>@@ -775,64 +775,73 @@
>> td_thrinfo_t ti;
>> td_err_e err;
>> CORE_ADDR stop_pc;
>>+ int loop = 0;
>>
>> /* Bail out early if we're not at a thread event breakpoint. */
>> stop_pc = read_pc_pid (ptid) - DECR_PC_AFTER_BREAK;
>> if (stop_pc != td_create_bp_addr && stop_pc != td_death_bp_addr)
>> return;
>>
>>- err = td_ta_event_getmsg_p (thread_agent, &msg);
>>- if (err != TD_OK)
>>+ /* If we are at a create breakpoint, we do not know what new lwp
>>+ was created and cannot specifically locate the event message for it.
>>+ We have to call td_ta_event_getmsg() to get
>>+ the latest message. Since we have no way of correlating whether
>>+ the event message we get back corresponds to our breakpoint, we must
>>+ loop and read all event messages, processing them appropriately.
>>+ This guarantees we will process the correct message before continuing
>>+ from the breakpoint.
>>+
>>+ Currently, death events are not enabled. If they are enabled,
>>+ the death event can use the td_thr_event_getmsg() interface to
>>+ get the message specifically for that lwp and avoid looping
>>+ below. */
>>+
>>+ loop = 1;
>>+
>>+ do
>> {
>>- if (err == TD_NOMSG)
>>- return;
>>+ err = td_ta_event_getmsg_p (thread_agent, &msg);
>>+ if (err != TD_OK)
>>+ {
>>+ if (err == TD_NOMSG)
>>+ return;
>>
>>- error ("Cannot get thread event message: %s", thread_db_err_str (err));
>>- }
>>+ error ("Cannot get thread event message: %s",
>>+ thread_db_err_str (err));
>>+ }
>>
>>- err = td_thr_get_info_p (msg.th_p, &ti);
>>- if (err != TD_OK)
>>- error ("check_event: cannot get thread info: %s",
>>- thread_db_err_str (err));
>>+ err = td_thr_get_info_p (msg.th_p, &ti);
>>+ if (err != TD_OK)
>>+ error ("Cannot get thread info: %s", thread_db_err_str (err));
>>
>>- ptid = BUILD_THREAD (ti.ti_tid, GET_PID (ptid));
>>+ ptid = BUILD_THREAD (ti.ti_tid, GET_PID (ptid));
>>
>>- switch (msg.event)
>>- {
>>- case TD_CREATE:
>>-#if 0
>>- /* FIXME: kettenis/2000-08-26: Since we use td_ta_event_getmsg,
>>- there is no guarantee that the breakpoint will match the
>>- event. Should we use td_thr_event_getmsg instead? */
>>-
>>- if (stop_pc != td_create_bp_addr)
>>- error ("Thread creation event doesn't match breakpoint.");
>>-#endif
>>-
>>- /* We may already know about this thread, for instance when the
>>- user has issued the `info threads' command before the SIGTRAP
>>- for hitting the thread creation breakpoint was reported. */
>>- if (!in_thread_list (ptid))
>>- attach_thread (ptid, msg.th_p, &ti, 1);
>>- return;
>>-
>>- case TD_DEATH:
>>-#if 0
>>- /* FIXME: See TD_CREATE. */
>>-
>>- if (stop_pc != td_death_bp_addr)
>>- error ("Thread death event doesn't match breakpoint.");
>>-#endif
>>+ switch (msg.event)
>>+ {
>>+ case TD_CREATE:
>>+
>>+ /* We may already know about this thread, for instance when the
>>+ user has issued the `info threads' command before the SIGTRAP
>>+ for hitting the thread creation breakpoint was reported. */
>>+ if (!in_thread_list (ptid))
>>+ attach_thread (ptid, msg.th_p, &ti, 1);
>>+
>>+ break;
>>+
>>+ case TD_DEATH:
>>+
>>+ if (!in_thread_list (ptid))
>>+ error ("Spurious thread death event.");
>>
>>- if (!in_thread_list (ptid))
>>- error ("Spurious thread death event.");
>>+ detach_thread (ptid, 1);
>>
>>- detach_thread (ptid, 1);
>>- return;
>>+ break;
>>
>>- default:
>>- error ("Spurious thread event.");
>>+ default:
>>+ error ("Spurious thread event.");
>>+ }
>> }
>>+ while (loop);
>> }
>>
>> static ptid_t
>
>
prev parent reply other threads:[~2003-06-04 23:39 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-04-23 21:16 J. Johnston
2003-06-02 19:18 ` Michael Snyder
2003-06-05 18:22 ` J. Johnston
2003-06-04 21:58 ` Joel Brobecker
2003-06-04 23:39 ` J. Johnston [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3EDE8335.5060708@redhat.com \
--to=jjohnstn@redhat.com \
--cc=brobecker@gnat.com \
--cc=gdb-patches@sources.redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox