From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp.polymtl.ca (smtp.polymtl.ca [132.207.4.11]) by sourceware.org (Postfix) with ESMTPS id 20C93396C4C8 for ; Thu, 8 Dec 2022 20:53:58 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 20C93396C4C8 Authentication-Results: sourceware.org; dmarc=pass (p=quarantine dis=none) header.from=polymtl.ca Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=polymtl.ca Received: from simark.ca (simark.ca [158.69.221.121]) (authenticated bits=0) by smtp.polymtl.ca (8.14.7/8.14.7) with ESMTP id 2B8KroF7010056 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 8 Dec 2022 15:53:54 -0500 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp.polymtl.ca 2B8KroF7010056 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=polymtl.ca; s=default; t=1670532835; bh=gM8gTgUCdTEPyxtRI22Zi9pdzwDyANYduJ2mmBmqKSg=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=BFu+F/MaRMC0aenTB73jVJUHajR55Qk42CJ135V4lWfPq5QkxgHby2z69KWPHIZd7 XwSuGKuV/Mhhkb+K1pEHUW34RDK4f183zUzpbCTACRpwYWzoR3+Nq45IkmrOAjeyCR w0DBLw0zSIHCNqolRPsAtOXJDqdlHtlKo/+1O76U= Received: from [132.207.214.75] (Sansfil-Eduroam-Externe-214-75.polymtl.ca [132.207.214.75]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPSA id EEBFB1E0CB; Thu, 8 Dec 2022 15:53:49 -0500 (EST) Message-ID: Date: Thu, 8 Dec 2022 15:53:49 -0500 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.4.1 Subject: Re: [PATCH 2/6] gdb: make it possible to restore selected user-created frames Content-Language: fr To: Bruno Larsen , gdb-patches@sourceware.org Cc: Simon Marchi References: <20221202180052.212745-1-simon.marchi@polymtl.ca> <20221202180052.212745-3-simon.marchi@polymtl.ca> From: Simon Marchi In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Poly-FromMTA: (simark.ca [158.69.221.121]) at Thu, 8 Dec 2022 20:53:50 +0000 X-Spam-Status: No, score=-3029.9 required=5.0 tests=BAYES_00,BODY_8BITS,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,NICE_REPLY_A,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,SPF_HELO_PASS,SPF_PASS,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: >> Now, the question is, how to identify a user-created frame through the >> selected_frame_level/selected_frame_id pair.  I initially added a >> separate "selected_frame_is_user_created" flag to that pair.  Then it >> seemed simpler to make it so user-created frames would be identified by >> the selected_frame_level == 0.  User-created frames already happen to >> have level 0.  And remember that when the saved frame is the current >> target frame, selected_frame_level is -1.  We need to modify >> select_frame in any case to make it so it will save the frame id and use >> the saved level 0 for user-created frames, despite them having level >> 0.  So just with that, it's possible to distinguish user-created frames, >> no need to add a separate flag.  It results in: > > But this doesn't necessarily sound correct if we're supposed to be > able to go up and down on user created frames. My best guess for such > a feature would be improving the debugging experience of optimized > programs or reverse engineering something. If you were able to > identify that something is an inlined function, for instance, you > could make an artificial frame to keep track of this information, so > that future executions (or just moving up and down the stack) was > easier.  If that guess is correct, it would be possible to have a user > created frame at a level that isn't level 0, and the detection method > fails. You are right, if it was possible to unwind from that user frame, I think we'd need to keep a separate flag to say "this frame was unwound from a user-created frame, not the target current frame". And we would probably need to keep that user-created frame id too (in addition to the selected frame id), to recreate it. But at the moment, since it's not possible to unwind go up / down from a user-created frame, I don't think we should account for that. If it ever becomes possible to unwind user-created frames, we can change the strategy then. >> @@ -1669,6 +1673,11 @@ get_current_frame (void) >>      never 0 and SELECTED_FRAME_ID is never the ID of the innermost >>      frame. >>   +   An exception to that is if the selected frame is a used-created one >> +   (created and selected through the "select-frame view" command).  That >> +   is encoded by having SELECTED_FRAME_LEVEL == 0 and SELECTED_FRAME_ID >> +   the frame id derived from the user-provided addresses. >> + > > I would slightly reword this comment so there isn't incorrect information if someone only reads part of it. Maybe something like: > >  If SELECTED_FRAME_ID / SELECTED_FRAME_LEVEL are null_frame_id / -1, >  and the target has stack and is stopped, the selected frame is the >  current (innermost) frame.  SELECTED_FRAME_ID is never the ID of the innermost >  frame. SELECTED_FRAME_LEVEL may be 0 only if the selected frame is a >  a user-created one (created and selected through the "select-frame view" >  command), in which case SELECTED_FRAME_ID is the frame id derived from > the user-provided addresses. > > This way there is no way someone can be confused by thinking that 0 is never acceptable. Thanks, I used that. >> +    # Verify that the "frame" command does not change the selected frame. >> +    gdb_test "frame" "#0  baz \\(z1=.*, z2=.*\\).*" "frame" >> +    gdb_test "frame" "#0  baz \\(z1=.*, z2=.*\\).*" "frame again" > I think it would be nice to have an explanation as to why frame is > being called twice. Just a mention that there was a bug where we'd > lose track of user-created frames when using the command "frame" would > be enough, I think. Hmm I think the current comment pretty much says that. By saying "Verify that the frame command does not change the selected frame", it implies there was a bug where the frame command did change the selected frame. But I can make it clearer if you'd like, comments are not expensive. Simon