From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by sourceware.org (Postfix) with ESMTPS id DC42339960EA for ; Mon, 12 Dec 2022 11:14:10 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org DC42339960EA Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1670843650; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=WkafsH18QVFeK1in6kw5YNu/nY7R7PAyto9blI+nJoI=; b=OG3vHQD2Ig5fv/F2QteiNDabFyjkpXs1fbS0Y/xsnJMDRMU5FJguU2frKjlchEcXVaGIm2 89Z7xNhADR+qPWuFEEIoEWqh/9kFzrQdzxVNMygx6uDEVEabO6OPNd8tBh/sJDTQRkkb12 MKD1DunErIO1N6rxgR3cP6n0n5YgYVk= Received: from mail-ed1-f71.google.com (mail-ed1-f71.google.com [209.85.208.71]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_128_GCM_SHA256) id us-mta-475-odjGNsTePBKzXvn7KdllTQ-1; Mon, 12 Dec 2022 06:14:09 -0500 X-MC-Unique: odjGNsTePBKzXvn7KdllTQ-1 Received: by mail-ed1-f71.google.com with SMTP id j6-20020a05640211c600b0046d6960b266so4807943edw.6 for ; Mon, 12 Dec 2022 03:14:09 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=WkafsH18QVFeK1in6kw5YNu/nY7R7PAyto9blI+nJoI=; b=TAhrmNNe+iPDOq1T6pK3Mf1ponb0HAWSQAgaVDnrb/bnt0XGQuIIt9GxlEU9sV68TC Pa/iRZyLN/KdIiPnNmfIOVxEZU7IgemmRbu07C+Y/8rtprOb8uzE7r/FszJh1gcJ7MHH nFd5zgJ1isA53q0ZDo+VXLWd10Nd0zH/nGMpOUZA/2h7T3Y1kHER4P2qOSu9hD6RnJSK ipFffdA8lhFAIt5a0SRxjLTOZhJHJsgrL5gKJOxCtcb6m88ajmP0e77lPenfDD/SD2/5 LklXkvEJ2kRAHTSqNU0+VGQJVdxomRZEnvYnyLmBS0Cik3r/l26TIyPcVVVcxLEqzPq5 8ksw== X-Gm-Message-State: ANoB5pnIgSwv3SbriPKeLP2fDy/7OiIVRj85Jb4UB6lEbnR/Nq/9PXII hgQ7DbdttFUN/M1g3XZf9MhFSVMIN1ykyaH3UQNL2rwHIOtEAlE75I6voaYwCcJmYB7u16jLQNK RM4IoRHNTV8M98ZPpdNtjwg== X-Received: by 2002:a17:907:d40c:b0:7c0:8a2c:8883 with SMTP id vi12-20020a170907d40c00b007c08a2c8883mr16017687ejc.56.1670843648204; Mon, 12 Dec 2022 03:14:08 -0800 (PST) X-Google-Smtp-Source: AA0mqf4eRGEnIAlzBcnJP/kymDf4B6SQjibqVeiHPusmN96kfEyere8A7KsbxRjeYgCeuBNo4SUHgQ== X-Received: by 2002:a17:907:d40c:b0:7c0:8a2c:8883 with SMTP id vi12-20020a170907d40c00b007c08a2c8883mr16017674ejc.56.1670843647956; Mon, 12 Dec 2022 03:14:07 -0800 (PST) Received: from [10.43.2.105] (nat-pool-brq-t.redhat.com. [213.175.37.10]) by smtp.gmail.com with ESMTPSA id kr12-20020a1709079a0c00b007ae10525550sm3125190ejc.47.2022.12.12.03.14.07 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 12 Dec 2022 03:14:07 -0800 (PST) Message-ID: <4abe5d7b-db2f-1651-b500-13e51303178d@redhat.com> Date: Mon, 12 Dec 2022 12:14:06 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.5.1 Subject: Re: [PATCH 2/6] gdb: make it possible to restore selected user-created frames To: Simon Marchi , gdb-patches@sourceware.org Cc: Simon Marchi References: <20221202180052.212745-1-simon.marchi@polymtl.ca> <20221202180052.212745-3-simon.marchi@polymtl.ca> From: Bruno Larsen In-Reply-To: X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-4.6 required=5.0 tests=BAYES_00,BODY_8BITS,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,NICE_REPLY_A,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_NONE,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: On 08/12/2022 21:53, Simon Marchi wrote: >>> 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. Makes sense. I agree with the patch, then Reviewed-By: Bruno Larsen > >>> @@ -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. Yeah, I guess you're right, I must have been a bit too tired when I read this to not notice the implication you mentioned. It's probably fine. -- Cheers, Bruno > > Simon >