Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Pedro Alves <pedro@palves.net>
To: Simon Marchi <simark@simark.ca>, gdb-patches@sourceware.org
Subject: Re: [PATCH 3/3] Make scoped_restore_current_thread's cdtors exception free (RFC)
Date: Thu, 9 Jul 2020 13:09:58 +0100	[thread overview]
Message-ID: <d9204691-5130-d970-6154-e8482180bc0f@palves.net> (raw)
In-Reply-To: <a33d6994-7be9-60f3-d218-5da7df64600f@palves.net>

On 7/9/20 12:56 PM, Pedro Alves wrote:
> On 7/9/20 4:49 AM, Simon Marchi wrote:
>>>  void
>>>  select_frame (struct frame_info *fi)
>>>  {
>>>    selected_frame = fi;
>>> +  selected_frame_level = frame_relative_level (fi);
>>> +  if (selected_frame_level == 0)
>>> +    {
>>> +      /* Treat the current frame especially -- we want to always
>>> +	 save/restore it without warning, even if the frame ID changes
>>> +	 (see restore_selected_frame).  Also get_frame_id may access
>>> +	 the target's registers/memory, and thus skipping get_frame_id
>>> +	 optimizes the common case.  */
>>> +      selected_frame_level = -1;
>>> +      selected_frame_id = null_frame_id;
>>> +    }
>>> +  else
>>> +    selected_frame_id = get_frame_id (fi);
>>> +
>>
>> I don't really understand this part, why don't we want to set selected_frame_level
>> and selected_frame_id when the level is 0.  I'm more interested by why it wouldn't
>> be correct or how it would break things, rather than the optimization aspect.
>>
> 
> At first, I was recording frame 0 normally, without that special case.
> But running the testsuite revealed regressions in a couple testcases:
> 
>  gdb.python/py-unwind-maint.exp
>  gdb.server/bkpt-other-inferior.exp
> 
> Both are related to the get_frame_id call.  Before the patch, get_frame_id
> isn't called on the current frame until you try to backtrace from it.
> Adding the get_frame_id call makes the gdb.python/py-unwind-maint.exp testcase
> print the Python unwinder callbacks in a different order, unexpected
> by the testcase.  I didn't look too deeply into this one, but I suspect
> it would just be a matter of adjusting the testcase's expectations.
> 
> The gdb.server/bkpt-other-inferior.exp one though is what got me
> thinking.  The testcase makes sure that setting a breakpoint in a
> function that doesn't exist in the remote inferior does not cause
> remote protocol traffic.  After the patch, without the special casing,
> the testcase would fail because the get_frame_id call, coming from 
> 
>  check_frame_language_change  # called after every command
>   -> get_selected_frame
>     -> restore_selected_frame
>       -> select_frame(get_current_frame())
>          -> get_frame_id
> 
> would cause registers and memory to be read from the remote target (when
> restoring the selected frame).  Those accesses aren't wrong, but they
> aren't the kind that the bug the testcase is looking for.  Those were
> about spurious/incorrect remote protocol accesses when parsing the
> function's prologue.
> 
> Neither of these cases were strictly incorrect, though they got me
> thinking, and I came to the conclusion that warning when we fail to
> re-find the current frame is pointless, and that avoids having
> unbreak the testcases mentioned, or even redo them differently in
> the gdb.server/bkpt-other-inferior.exp case.
> 
> I've updated the comment to make it clearer with an example.
> 
> I've also polished the patch some more.  I now renamed
> the current restore_selected_frame to lookup_selected_frame,
> to give space to the new save_selected_frame/restore_selected_frame
> pair.  select_frame_lazy is now restore_selected_frame.
> save_selected_frame/restore_selected_frame are now noexcept, and
> their intro comments explain why.
> 
> I declared lookup_selected_frame in frame.h already, thinking that
> it's easier if I move lookup_selected_frame from thread.c to frame.c
> after this is in, instead of before.
> 
> I rewrote most of the comments.  For example, I think the
> selected_frame_id/selected_frame_level/selected_frame comments are now
> much clearer.
> 
> And I made scoped_restore_selected_frame save/restore the language
> too.  I was only doing that in scoped_restore_current_thread before.
> 
> Let me know what you think of this version.

I've pushed this, along with all the PR26199 patches to:

 users/palves/pr26199-busy-loop-target-events

(The version pushed has a couple comment typos fixed compared to the
one posted.)


  reply	other threads:[~2020-07-09 12:10 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-07-08 23:31 [PATCH 0/3] Fix crash if connection drops in scoped_restore_current_thread's ctor Pedro Alves
2020-07-08 23:31 ` [PATCH 1/3] Fix crash if connection drops in scoped_restore_current_thread's ctor, part 1 Pedro Alves
2020-07-09  3:17   ` Simon Marchi
2020-07-09 10:51     ` Pedro Alves
2020-07-09 14:13       ` Simon Marchi
2020-07-08 23:31 ` [PATCH 2/3] Fix crash if connection drops in scoped_restore_current_thread's ctor, part 2 Pedro Alves
2020-07-09  3:31   ` Simon Marchi
2020-07-09 11:12     ` Pedro Alves
2020-07-09 14:16       ` Simon Marchi
2020-07-09 17:23         ` Pedro Alves
2020-07-09 17:28           ` Simon Marchi
2020-07-08 23:31 ` [PATCH 3/3] Make scoped_restore_current_thread's cdtors exception free (RFC) Pedro Alves
2020-07-09  3:49   ` Simon Marchi
2020-07-09 11:56     ` Pedro Alves
2020-07-09 12:09       ` Pedro Alves [this message]
2020-07-09 15:40       ` Simon Marchi
2020-07-09 22:22         ` Pedro Alves
2020-07-10  2:55           ` Simon Marchi
2020-10-30  1:13             ` Pedro Alves
2020-10-30  1:37               ` [pushed] Move lookup_selected_frame to frame.c Pedro Alves
2020-10-30  7:44               ` [PATCH 3/3] Make scoped_restore_current_thread's cdtors exception free (RFC) Aktemur, Tankut Baris via Gdb-patches
2020-10-30 11:32                 ` Pedro Alves
2020-10-31 14:35                   ` [PATCH] Fix frame cycle detection (Re: [PATCH 3/3] Make scoped_restore_current_thread's cdtors exception free (RFC)) Pedro Alves
2020-11-09 14:05                     ` Aktemur, Tankut Baris via Gdb-patches
2020-11-16 13:48                       ` Tom de Vries
2020-11-16 14:57                         ` Pedro Alves
2020-07-10 23:02 ` [PATCH 0/3] Fix crash if connection drops in scoped_restore_current_thread's ctor Pedro Alves
2020-07-22 19:37   ` Simon Marchi
2020-07-22 20:37     ` Pedro Alves
2020-07-22 20:47       ` Simon Marchi
2020-07-23 15:28         ` [pushed] Don't touch frame_info objects if frame cache was reinitialized (was: Re: [PATCH 0/3] Fix crash if connection drops in scoped_restore_current_thread's ctor) Pedro Alves

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=d9204691-5130-d970-6154-e8482180bc0f@palves.net \
    --to=pedro@palves.net \
    --cc=gdb-patches@sourceware.org \
    --cc=simark@simark.ca \
    /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