From: Vladimir Prus <vladimir@codesourcery.com>
To: Nick Roberts <nickrob@snap.net.nz>
Cc: gdb@sources.redhat.com
Subject: Re: MI non-stop mode spec
Date: Mon, 24 Mar 2008 05:44:00 -0000 [thread overview]
Message-ID: <200803231225.31593.vladimir@codesourcery.com> (raw)
In-Reply-To: <18405.57137.166048.407495@kahikatea.snap.net.nz>
On Sunday 23 March 2008 07:40:17 Nick Roberts wrote:
> > > > > > Didn't you check in a patch to make *-varobjs be found to a
> > > > > > thread?
> > > > >
> > > > > I submitted a patch earlier this year that stopped thinking that
> > > > > a variable object had gone out of scope if the thread changed
> > > > > but nothing happened.
> > > >
> > > > Can you resend the current version of that patch, and I'll take a
> > > > look.
> > >
> > > I used pid_to_thread_id (inferior_ptid) for the thread_id, just as
> > > infrun.c does for *stopped. I think that the thread_id problem for
> > > single/multi-threaded programs should be fixed first (perhaps along
> > > the lines Daniel suggested).
> >
> > Dan's patch is in, however, it only affects Linux. I suspect in might
> > be a long time till the problem is solved on all system. Until then,
> > we probably should assume that if thread list is empty, then the
> > program is ST and never will become MT.
> >
> > I happen to be working on variable objects for non-stop now, so I'll
> > play with the last version of your patch that you have posted.
>
> I've made some changes since then so here's my latest patch updated to current
> sources. I found that after all I did need thread_id == -2 for global
> variables (used in mi-cmd-var which doesn't print the thread_id field for them
> since their value is the same in all threads).
I don't think we need it. A global variable has a NULL valid_block, so we can
use that. I'll work on adjusting your patch this way.
> static struct value *
> c_value_of_root (struct varobj **var_handle)
> {
> struct value *new_val = NULL;
> struct varobj *var = *var_handle;
> ! struct frame_id saved_frame_id;
> ! struct cleanup *old_cleanups = NULL;
> ! int within_scope, thread_id;
> ! ptid_t ptid;
>
> /* Only root variables can be updated... */
> if (!is_root_p (var))
> /* Not a root var */
> return NULL;
>
> /* Determine whether the variable is still around. */
> if (var->root->valid_block == NULL || var->root->use_selected_frame)
> within_scope = 1;
> else
> {
> ! thread_id = var->root->thread_id;
> ! ptid = thread_id_to_pid (thread_id);
> ! if (thread_id == 0)
> ! /* Single-threaded application. */
> ! within_scope = check_scope (var);
> ! else if (thread_id != -1 && target_thread_alive (ptid))
> {
> !
> ! saved_frame_id = get_frame_id (get_selected_frame (NULL));
> ! old_cleanups = make_cleanup_restore_current_thread (inferior_ptid,
> ! saved_frame_id);
> ! switch_to_thread (ptid);
> ! within_scope = check_scope (var);
> ! }
> ! else
> ! /* Mark it as dead. */
> ! var->root->thread_id = -1;
> }
>
> if (within_scope)
> *************** c_value_of_root (struct varobj **var_han
> *** 2186,2191 ****
> --- 2233,2240 ----
> return new_val;
> }
>
> + do_cleanups (old_cleanups);
> +
> return NULL;
> }
I think the use of cleanups above is wrong. You basically have:
struct cleanups *old_cleanups = NULL;
if (whatever)
old_cleanups = ...
do_cleanups (old_cleanups);
so, if 'whatever' evaluates to false, all cleanups, including those set
in parent, will be executed.
That's what we get for using a language that does not have exceptions
and proper destructors. I'll fix this too.
- Volodya
next prev parent reply other threads:[~2008-03-23 9:25 UTC|newest]
Thread overview: 52+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-03-19 2:49 Vladimir Prus
2008-03-19 6:26 ` Nick Roberts
2008-03-19 9:14 ` Vladimir Prus
2008-03-19 10:02 ` Nick Roberts
2008-03-19 11:10 ` Vladimir Prus
2008-03-19 12:30 ` Nick Roberts
2008-03-19 13:43 ` Vladimir Prus
2008-03-19 20:44 ` Michael Snyder
2008-03-19 11:20 ` Bob Rossi
2008-03-19 11:16 ` Bob Rossi
2008-03-19 12:01 ` Vladimir Prus
2008-03-19 13:50 ` Bob Rossi
2008-03-19 14:07 ` Vladimir Prus
2008-03-19 14:33 ` Bob Rossi
2008-03-19 16:09 ` Vladimir Prus
2008-03-20 18:22 ` Marc Khouzam
2008-03-20 20:02 ` Vladimir Prus
2008-03-21 9:11 ` Nick Roberts
2008-03-21 9:48 ` Vladimir Prus
2008-03-21 18:13 ` Nick Roberts
2008-03-22 0:33 ` Vladimir Prus
2008-03-23 4:41 ` Nick Roberts
2008-03-23 5:18 ` Vladimir Prus
2008-03-23 9:25 ` Nick Roberts
2008-03-24 5:44 ` Vladimir Prus [this message]
2008-03-24 7:05 ` Thread bound variable objects [was: Re: MI non-stop mode spec] Nick Roberts
2008-03-24 7:18 ` Vladimir Prus
2008-03-24 11:04 ` Nick Roberts
2008-03-24 14:38 ` Vladimir Prus
2008-03-25 6:28 ` Thread bound variable objects Nick Roberts
2008-03-25 11:34 ` Daniel Jacobowitz
2008-03-21 11:52 ` MI non-stop mode spec Vladimir Prus
2008-03-24 23:14 ` Daniel Jacobowitz
2008-03-25 17:46 ` Vladimir Prus
2008-03-22 17:33 ` Pawel Piech
2008-03-24 4:03 ` Nick Roberts
2008-03-24 17:22 ` Pawel Piech
2008-03-24 20:23 ` Vladimir Prus
2008-03-25 2:14 ` Nick Roberts
2008-03-24 18:38 ` Vladimir Prus
2008-03-24 21:25 ` Pawel Piech
2008-03-24 21:46 ` Vladimir Prus
2008-03-24 22:28 ` Pawel Piech
2008-03-25 12:30 ` Vladimir Prus
2008-03-25 18:30 ` Pawel Piech
2008-03-27 14:13 ` Vladimir Prus
2008-03-27 19:39 ` Pawel Piech
2008-03-25 21:28 ` Nick Roberts
2008-03-26 13:03 ` Pawel Piech
2008-03-25 1:00 ` Daniel Jacobowitz
2008-03-25 18:18 ` Pawel Piech
2008-03-30 21:36 ` Pawel Piech
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=200803231225.31593.vladimir@codesourcery.com \
--to=vladimir@codesourcery.com \
--cc=gdb@sources.redhat.com \
--cc=nickrob@snap.net.nz \
/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