Mirror of the gdb mailing list
 help / color / mirror / Atom feed
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


  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