From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx0b-001b2d01.pphosted.com (mx0b-001b2d01.pphosted.com [148.163.158.5]) by sourceware.org (Postfix) with ESMTPS id 18564385840F for ; Thu, 20 Jul 2023 14:45:37 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 18564385840F Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=us.ibm.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=us.ibm.com Received: from pps.filterd (m0353725.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.17.1.19/8.17.1.19) with ESMTP id 36KE7p9E000536; Thu, 20 Jul 2023 14:45:31 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ibm.com; h=message-id : from : to : cc : date : in-reply-to : references : content-type : mime-version : content-transfer-encoding : subject; s=pp1; bh=YMYcDpDVQToA4A7qoz1Xi+OClpco1EtqAQ8t7+wuWRE=; b=MHqoG+/rRHuaoCq4P3kjyXyyD68FyEMYzdzl7Wb0SvuXTdgQTUGL5qxNsce8fAb8KFTr mc1bzzchUBFC4SPRL3KgOY59s87x+oC4Qi6w9RfpW7KWY9aKmKstX82bIsQylZj3/IuW CzUvxcBeAOLR+PfSVJ0f5KlNbjA4ZzpmoM53b+taEoKE0vnEqzdKLNwhnOfhtWK0RFTF fw/cuIVq9t5P9agZ3f+FA47PXx63gVs+sFzXpfPycecK1bc2+6VXwvAU9okeQA3NhbJE NH5bT0zT4+xmKL1gVwVtTOW96NRgfaK9HhPcAnX5rzgZw1PT0XXFloumbY8STEuznYXZ Fw== Received: from pps.reinject (localhost [127.0.0.1]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 3rxwcgx2ty-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 20 Jul 2023 14:45:30 +0000 Received: from m0353725.ppops.net (m0353725.ppops.net [127.0.0.1]) by pps.reinject (8.17.1.5/8.17.1.5) with ESMTP id 36KEcV3n012735; Thu, 20 Jul 2023 14:45:29 GMT Received: from ppma13.dal12v.mail.ibm.com (dd.9e.1632.ip4.static.sl-reverse.com [50.22.158.221]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 3rxwcgx2td-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 20 Jul 2023 14:45:29 +0000 Received: from pps.filterd (ppma13.dal12v.mail.ibm.com [127.0.0.1]) by ppma13.dal12v.mail.ibm.com (8.17.1.19/8.17.1.19) with ESMTP id 36KCo3oP008046; Thu, 20 Jul 2023 14:45:29 GMT Received: from smtprelay04.wdc07v.mail.ibm.com ([172.16.1.71]) by ppma13.dal12v.mail.ibm.com (PPS) with ESMTPS id 3rv80jcrx5-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 20 Jul 2023 14:45:29 +0000 Received: from smtpav03.wdc07v.mail.ibm.com (smtpav03.wdc07v.mail.ibm.com [10.39.53.230]) by smtprelay04.wdc07v.mail.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 36KEjSLd29491732 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 20 Jul 2023 14:45:28 GMT Received: from smtpav03.wdc07v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 0BD575805F; Thu, 20 Jul 2023 14:45:28 +0000 (GMT) Received: from smtpav03.wdc07v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 6390158054; Thu, 20 Jul 2023 14:45:26 +0000 (GMT) Received: from li-e362e14c-2378-11b2-a85c-87d605f3c641.ibm.com (unknown [9.61.185.149]) by smtpav03.wdc07v.mail.ibm.com (Postfix) with ESMTP; Thu, 20 Jul 2023 14:45:25 +0000 (GMT) Message-ID: <38ab07a7a217bcc05be78c82d351aef73b411fb9.camel@us.ibm.com> From: Carl Love To: Bruno Larsen , Simon Marchi , Tom de Vries , Ulrich Weigand , "gdb-patches@sourceware.org" , "pedro@palves.net" Cc: cel@us.ibm.com Date: Thu, 20 Jul 2023 07:45:20 -0700 In-Reply-To: <6c58d4ce-d9ff-e1d9-398b-724859394f22@redhat.com> References: <71aa635593df0677811afb85409aa190bcfa4f6a.camel@us.ibm.com> <15864a6b87b25c93e99a28149f23138267735f2a.camel@us.ibm.com> <041f62e9f26fd4a536bc90c34f072985582e6237.camel@de.ibm.com> <46c2c756475ba5923d7eed97996632a08285dd42.camel@us.ibm.com> <65861786-069e-53a1-ca17-a525b6629c95@suse.de> <5be0c849abeef84d34a6ff255fb2705ca5dcb035.camel@us.ibm.com> <5e60a837-b21c-011f-c94e-e8bbf7645c5d@simark.ca> <7639de48695d52a806627b0a91979ad2e5fd9b42.camel@us.ibm.com> <9cf51eb9-c731-6f42-ab2b-a37048f25d12@simark.ca> <60c362e6dadd05754907af5f10e6f3c0423e1901.camel@us.ibm.com> <2a1d55cb-118b-d942-b315-a5f2348894f5@simark.ca> <0ab7af40f2f8d1edbceea851c37282a03c830567.camel@us.ibm.com> <90c98190-f8eb-1d64-43ce-8bab67d5caef@simark.ca> <6c58d4ce-d9ff-e1d9-398b-724859394f22@redhat.com> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.28.5 (3.28.5-18.el8) Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-TM-AS-GCONF: 00 X-Proofpoint-GUID: AogEpugS-nWIzM3rZHnKJod0vFPR1KNv X-Proofpoint-ORIG-GUID: 4iiPi3tU-9DLhVunhG3kiYAkDDsmgOwB Subject: RE: [PATCH 2/2 ] PowerPC: fix for gdb.reverse/finish-precsave.exp and gdb.reverse/finish-reverse.exp X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.254,Aquarius:18.0.957,Hydra:6.0.591,FMLib:17.11.176.26 definitions=2023-07-20_07,2023-07-20_01,2023-05-22_02 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 malwarescore=0 bulkscore=0 phishscore=0 mlxlogscore=842 suspectscore=0 impostorscore=0 adultscore=0 spamscore=0 lowpriorityscore=0 mlxscore=0 priorityscore=1501 clxscore=1011 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2306200000 definitions=main-2307200122 X-Spam-Status: No, score=-4.8 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_EF,KAM_MANYTO,RCVD_IN_MSPIKE_H5,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE,SPF_NONE,TXREP,T_SCC_BODY_TEXT_LINE 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: Bruno: On Thu, 2023-07-20 at 14:01 +0200, Bruno Larsen wrote: > (gdb) disas /s > (snip) > 81 b = 5; > 0x00000000004011bb <+43>: movl $0x5,-0x18(%rbp) > > 82 > 83 function1 (a, b); // CALL VIA LEP > 0x00000000004011c2 <+50>: mov -0x14(%rbp),%edi > 0x00000000004011c5 <+53>: mov -0x18(%rbp),%esi > => 0x00000000004011c8 <+56>: call 0x401140 > (gdb) rn > 81 b = 5; > > Basically, the best way to fix this solution is to get reverse-next > and > reverse-step to properly figure out the stepping range and not have > a > reverse-next that ends up in the same line --------------------- Per my reply to Simon in "Re: [EXTERNAL] Re: [PATCH 2/2 v5] Fix reverse stepping multiple contiguous PC ranges over the line table." on 6/23/2023. Where he was wondering why control.step_range_start was not set to the "real" range.... This is the code in the Patch: > > > +{ > > + /* The line table may have multiple entries for the same source > > code line. > > + Given the PC, check the line table and return the PC that > > corresponds > > + to the line table entry for the source line that PC is > > in. */ > > + CORE_ADDR start_line_pc = ecs->event_thread- > > >control.step_range_start; > > + gdb::optional real_range_start; > > + > > + /* Call find_line_range_start to get the smallest address in the > > + linetable for multiple Line X entries in the line table. */ > > + real_range_start = find_line_range_start (pc); > > + > > + if (real_range_start.has_value ()) > > + start_line_pc = *real_range_start; > > + > > + return start_line_pc; Simon's comment about the code: > > When I read this, I wonder: why was control.step_range_start not set > to > the "real" range start in the first place (not only in the context of > reverse execution, every time it is set)? It would seem more robust > than patching it afterwards in some very specific spots. > > I could see some benefits for range-stepping uses cases too (relevant > when debugging remotely). Using your example here: > > Line X - [0x0 - 0x8] > Line X - [0x8 - 0x10] > Line X - [0x10 - 0x18] > > Imagine we are stopped at 0x14, and we type "next", and 0x14 is a > conditional jump to 0x5. It seems like current GDB would send a > "range > step" request to GDBserver, to step in the [0x10, 0x18[ range. When > reaching 0x5, execution would stop, and GDB would resume it again > with > the [0x0,0x8[ range. When reaching 0x8, it would stop again, GDB > would > resume it with [0x8,0x10[, and so on. If GDB could send a "range > step" > request with the [0x0,0x18[ range, it would avoid those unnecessary > intermediary stop. > My reply to Simon's comment: We looked at trying to set control.step_range_start to the real start range initially. Ulrich brought this point up in our internal review of the patch. So, when I am in function finish_backward() in infcmd.c I have no way to determine what the previous PC was. If I assume it was the previous value, i.e. pc - 4byes (on PowerPC). I get a gdb internal error. It seems that I am not allowed to change the line range to something that does not include the current pc value. ../../binutils-gdb-reverse-multiple-contiguous/gdb/infrun.c:2740: internal-error: resume_1: Assertion `pc_in_thread_step_range (pc, tp)' failed. In order to make that work, we concluded that it would probably entail a much bigger change to how reverse execution works which would be beyond the scope of what this patch is trying to fix. So, being able to do what I believe you want to do is in theory possible but it would require a larger, independent change to what this patch is trying to fix. --------------------------------------- I think what Bruno is again asking is to have control.step_range_start set to the real start range initially, i.e. what Simon asked about. I think to do that, we would need to make significant changes to how reverse execution works to allow us to make that change. It didn't appear to be a straight forward fix to me. I may be wrong. Maybe someone sees a good way to make that work that I am missing. So it looks like this patch fixes most issues but not all of the problems with reverse-step and reverse-next. It might be good to try and fix this additional scenario in a separate patch, not sure??? Carl