From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx0a-001b2d01.pphosted.com (mx0b-001b2d01.pphosted.com [148.163.158.5]) by sourceware.org (Postfix) with ESMTPS id 0CDE93858C52 for ; Sat, 14 Jan 2023 18:08:46 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 0CDE93858C52 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 (m0098420.ppops.net [127.0.0.1]) by mx0b-001b2d01.pphosted.com (8.17.1.19/8.17.1.19) with ESMTP id 30EEhwT1001484 for ; Sat, 14 Jan 2023 18:08:45 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=BY0WpJuFyDXoaO+I9n6Jh/EOZOetjbfT0T3Ts5hvtWw=; b=EcxzZUBZVlbBaEel0Rkm3caPPByU+QnDUv2IDZC7g7PIbC179McZWr/ws9ptB/Q+XmxM MXCQd2pj/EYMPod0UY0X1ekoCBb938TqXx1K+e4/CNPZEiTHvrCQbmpqGESh6TQE6RVl 8NSQ/6hka5bcd8w/VsAiRb+q61525gaIwZHlQWk1IRa8BNlhfrb8mCJynC183h1VxvV+ /0qAs9JGvW5wex2wlUNUZvyab3FI2dtJLlZAeWKpiv+betzJYDpQJSPfXUALMAFRcojI xni/eFi3M32XCYkmxGVPKbwPPEmngHW4RVOrmj0xXhC1fS5EdBIn3paK/hDT0+ZZUlvJ QQ== Received: from pps.reinject (localhost [127.0.0.1]) by mx0b-001b2d01.pphosted.com (PPS) with ESMTPS id 3n3xdntgbc-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Sat, 14 Jan 2023 18:08:45 +0000 Received: from m0098420.ppops.net (m0098420.ppops.net [127.0.0.1]) by pps.reinject (8.17.1.5/8.17.1.5) with ESMTP id 30EI8jjL016357 for ; Sat, 14 Jan 2023 18:08:45 GMT Received: from ppma01dal.us.ibm.com (83.d6.3fa9.ip4.static.sl-reverse.com [169.63.214.131]) by mx0b-001b2d01.pphosted.com (PPS) with ESMTPS id 3n3xdntgb8-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sat, 14 Jan 2023 18:08:44 +0000 Received: from pps.filterd (ppma01dal.us.ibm.com [127.0.0.1]) by ppma01dal.us.ibm.com (8.17.1.19/8.17.1.19) with ESMTP id 30EHUMlr008888; Sat, 14 Jan 2023 18:08:44 GMT Received: from smtprelay07.wdc07v.mail.ibm.com ([9.208.129.116]) by ppma01dal.us.ibm.com (PPS) with ESMTPS id 3n3m16vkma-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sat, 14 Jan 2023 18:08:44 +0000 Received: from smtpav02.wdc07v.mail.ibm.com (smtpav02.wdc07v.mail.ibm.com [10.39.53.229]) by smtprelay07.wdc07v.mail.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 30EI8gdQ6226458 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Sat, 14 Jan 2023 18:08:42 GMT Received: from smtpav02.wdc07v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id C2D505805D; Sat, 14 Jan 2023 18:08:42 +0000 (GMT) Received: from smtpav02.wdc07v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 1D1085805B; Sat, 14 Jan 2023 18:08:42 +0000 (GMT) Received: from li-e362e14c-2378-11b2-a85c-87d605f3c641.ibm.com (unknown [9.163.12.142]) by smtpav02.wdc07v.mail.ibm.com (Postfix) with ESMTP; Sat, 14 Jan 2023 18:08:41 +0000 (GMT) Message-ID: <8c7659147fcfd0cb046ed5dba0dd4d4f06411fb2.camel@us.ibm.com> From: Carl Love To: Bruno Larsen , Ulrich Weigand , "will_schmidt@vnet.ibm.com" , gdb-patches@sourceware.org Cc: cel@us.ibm.com Date: Sat, 14 Jan 2023 10:08:41 -0800 In-Reply-To: <219db4f7-1ce4-59c0-ae7a-1d99c460761f@redhat.com> References: <5b50668cbe882c57b8c0e9dcf5be0a253713c4c6.camel@us.ibm.com> <51c4bfc82ac72e475e10577dc60e4d75fa48767e.camel@de.ibm.com> <3ea97a8aa9cccb39299adde682f92055d1986ab3.camel@us.ibm.com> <53878e37c6e57de1d04d9c9960c5d0a74324ee6e.camel@us.ibm.com> <50474aa92ba82eff05cdc8f49001eae56be29670.camel@us.ibm.com> <89331c26795e3f7743e1e068dce43b3c2dd53008.camel@us.ibm.com> <071f24ecf9b3a2bbbe8fee7db77492eb55c5f3ff.camel@us.ibm.com> <1d9b21914354bef6a290ac30673741e722e11757.camel@de.ibm.com> <219db4f7-1ce4-59c0-ae7a-1d99c460761f@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: WajgmCH4bhoWGfMDMxml23T46wP-vnEP X-Proofpoint-ORIG-GUID: NIzhQiXlf1SVwfizw_WB77uXTD14ONJp Subject: RE: [PATCH 2/2] fix for gdb.reverse/finish-precsave.exp and gdb.reverse/finish-reverse.exp X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.219,Aquarius:18.0.923,Hydra:6.0.562,FMLib:17.11.122.1 definitions=2023-01-14_06,2023-01-13_02,2022-06-22_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 bulkscore=0 adultscore=0 malwarescore=0 suspectscore=0 lowpriorityscore=0 spamscore=0 mlxlogscore=999 mlxscore=0 impostorscore=0 clxscore=1015 phishscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2212070000 definitions=main-2301140132 X-Spam-Status: No, score=-11.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_EF,GIT_PATCH_0,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 Fri, 2023-01-13 at 16:55 +0100, Bruno Larsen wrote: > On 11/01/2023 19:27, Carl Love via Gdb-patches wrote: > > GDB maintainers: > > > > This patch fixes the issues with the reverse-finish command on > > PowerPC. The reverse-finish command now correctly stops at the > > first > > instruction in the source code line of the caller. > > > > The patch adds tests for calling a function via the GEP to the new > > test > > gdb.reverse/finish-reverse-next.exp. > > > > Please let me know if you have any comments on the patch. Thanks. > I'm not all that familiar with PowerPC ABI and I dont have a > computer > handy to test that the patch fixes the problem, but the logic seems > sound. Just a few nits inlined. > > Carl > > > > -------------------------------------------------------------- > > PowerPC: fix for gdb.reverse/finish-precsave.exp and > > gdb.reverse/finish-reverse.exp > > > > PowerPC uses two entry points called the local entry point (LEP) > > and the > > global entry point (GEP). Normally the LEP is used when calling a > > function. However, if the table of contents (TOC) value in > > register 3 is not valid the GEP is called to setup the TOC before > > execution > > continues at the LEP. When executing in reverse, the function > > finish_backward sets the break point at the alternate entry point > > (GEP). > > However if the forward execution enters via the normal entry point > > (LEP), > > the reverse execution never sees the break point at the GEP of the > > function. Reverse execution continues until the next break point > > is > > encountered or the end of the recorded log is reached causing gdb > > to stop > > at the wrong place. > > > > This patch adds a new address to struct execution_control_state to > > hold the > > address of the alternate function start address, known as the GEP > > on > > PowerPC. The finish_backwards function is updated. If the > > stopping point > > is between the two entry points (the LEP and GEP on PowerPC) , the > > stepping > > range is set to execute back to the alternate entry point (GEP on > > PowerPC). > > Otherwise, a breakpoint is inserted at the normal entry point (LEP > > on > > PowerPC). > > > > Function process_event_stop_test checks uses a stepping range to > > stop > > execution in the caller at the first instruction of the source code > > line. > > Note, on systems that only support one entry point, the address of > > the two > > entry points are the same. > > > > Test finish-reverse-next.exp is updated to include tests for the > > reverse-finish command when the function is entered via the normal > > entry > > point (i.e. the LEP) and the alternate entry point (i.e. the GEP). > > > > The patch has been tested on X86 and PowerPC with no regressions. > > --- > > gdb/infcmd.c | 41 ++++--- > > gdb/infrun.c | 21 +++- > > .../gdb.reverse/finish-reverse-next.c | 41 ++++++- > > .../gdb.reverse/finish-reverse-next.exp | 107 > > +++++++++++++++--- > > 4 files changed, 175 insertions(+), 35 deletions(-) > > > > diff --git a/gdb/infcmd.c b/gdb/infcmd.c > > index 9c42efeae8d..8c30af448ce 100644 > > --- a/gdb/infcmd.c > > +++ b/gdb/infcmd.c > > @@ -1722,22 +1722,28 @@ finish_backward (struct finish_command_fsm > > *sm) > > sal = find_pc_line (func_addr, 0); > > > > frame_info_ptr frame = get_selected_frame (nullptr); > > + struct gdbarch *gdbarch = get_frame_arch (frame); > > + CORE_ADDR alt_entry_point = sal.pc; > > + CORE_ADDR entry_point = alt_entry_point; > > > > - if (sal.pc != pc) > > + if (gdbarch_skip_entrypoint_p (gdbarch)) > > { > > - struct gdbarch *gdbarch = get_frame_arch (frame); > > + /* Some architectures, like PowerPC use local and global > > entry > > + points. There is only one Entry Point (GEP = LEP) for other > > + architectures. The GEP is an alternate entry point that is > > used > > + setup the table of contents (TOC) in register r2 before > > execution > > + continues at the LEP. The LEP is the normal entry point. > I don't think an explanation on why there are 2 entry points is > necessary. just mentioning that both exist is enough IMHO. OK, took out the additional detail in the comment. > > + The value of entry_point was initialized to the alternate > > entry > > + point (GEP). It will be adjusted if the normal entry point > > + (LEP) was used. */ > > + entry_point = gdbarch_skip_entrypoint (gdbarch, > > entry_point); > > > > - /* Set a step-resume at the function's entry point. Once > > that's > > - hit, we'll do one more step backwards. */ > > - symtab_and_line sr_sal; > > - sr_sal.pc = sal.pc; > > - sr_sal.pspace = get_frame_program_space (frame); > > - insert_step_resume_breakpoint_at_sal (gdbarch, > > - sr_sal, null_frame_id); > > } > > - else > > + > > + if (alt_entry_point <= pc && pc <= entry_point) > > { > > - /* We are exactly at the function entry point. Note that > > this > > + /* We are exactly at the function entry point, or between > > the entry > > + point on platforms that have two (like PowerPC). Note that > > this > > can only happen at frame #0. > > > > When setting a step range, need to call set_step_info > > @@ -1746,8 +1752,17 @@ finish_backward (struct finish_command_fsm > > *sm) > > > > /* Return using a step range so we will keep stepping back > > to the first instruction in the source code line. */ > > - tp->control.step_range_start = sal.pc; > > - tp->control.step_range_end = sal.pc; > > + tp->control.step_range_start = alt_entry_point; > > + tp->control.step_range_end = alt_entry_point; > I'm hesitant in this part. What if there is one instruction between > the > GEP and the LEP and the inferior happens to be stopped there? Could > this > happen? Yes, if the user did a step instruction from the caller and stopped on the second instruction in the function. Note, there is actually one instruction between the GEP instruction and the LEP instruction. > Like I said, I'm not familiar with the PPC abi, so excuse me if > the answer is obvious, but it seems to me that the step_range_end > could > be set to the entry_point and we'd avoid this possibility. Yes, that might be a little safer. Changed to set step_range_end to entry_point. the LEP which occurs two instructions after the GEP. > > + } > > + else > > + { > > + symtab_and_line sr_sal; > > + /* Set a step-resume at the function's entry point. */ > > + sr_sal.pc = entry_point; > > + sr_sal.pspace = get_frame_program_space (frame); > > + insert_step_resume_breakpoint_at_sal (gdbarch, > > + sr_sal, null_frame_id); > > } > > proceed ((CORE_ADDR) -1, GDB_SIGNAL_DEFAULT); > > } > > diff --git a/gdb/infrun.c b/gdb/infrun.c > > index 8ed538ea9ec..89423556ec0 100644 > > --- a/gdb/infrun.c > > +++ b/gdb/infrun.c > > @@ -1868,6 +1868,7 @@ struct execution_control_state > > > > struct target_waitstatus ws; > > int stop_func_filled_in = 0; > > + CORE_ADDR stop_func_alt_start = 0; > > CORE_ADDR stop_func_start = 0; > > CORE_ADDR stop_func_end = 0; > > const char *stop_func_name = nullptr; > > @@ -4663,6 +4664,14 @@ fill_in_stop_func (struct gdbarch *gdbarch, > > &block); > > ecs->stop_func_name = gsi == nullptr ? nullptr : gsi- > > >print_name (); > > > > + /* PowerPC functions have a Local Entry Point and a Global > > Entry > > + Point. There is only one Entry Point (GEP = LEP) for other > > + architectures. The GEP is an alternate entry point that is > > used > > + setup the table of contents (TOC) in register r2 before > > execution > > + continues at the LEP. Save the alternate entry point address > > for > Ditto here about explaining LEP and GEP. Just saying that GEP is the > alternate is probably enough. OK, removed the additional explanation from both places in the GDB code. I did leave the extra descripion in the test case where I gave the sample assembly code. My feeling is having that extra information is useful in the test case to explain what the specific test scenarios are doing and why is helpful. Having the extra detail repeated three times in the gdb source code and test case is probably a bit much. > > + use later. */ > > + ecs->stop_func_alt_start = ecs->stop_func_start; > > + > > /* The call to find_pc_partial_function, above, will set > > stop_func_start and stop_func_end to the start and end > > of the range containing the stop pc. If this range > > @@ -4679,6 +4688,9 @@ fill_in_stop_func (struct gdbarch *gdbarch, > > += gdbarch_deprecated_function_start_offset (gdbarch); > > > > if (gdbarch_skip_entrypoint_p (gdbarch)) > > + /* The PowerPC architecture uses two entry points. Stop at > > the > > + regular entry point (LEP on PowerPC) initially. Will > > setup a > > + breakpoint for the alternate entry point (GEP) > > later. */ > > ecs->stop_func_start > > = gdbarch_skip_entrypoint (gdbarch, ecs- > > >stop_func_start); > > } > > @@ -6738,8 +6750,7 @@ process_event_stop_test (struct > > execution_control_state *ecs) > > delete_step_resume_breakpoint (ecs->event_thread); > > fill_in_stop_func (gdbarch, ecs); > > > > - if (execution_direction == EXEC_REVERSE > > - && ecs->event_thread->stop_pc () == ecs->stop_func_start) > > + if (execution_direction == EXEC_REVERSE) > Why is this change not in the previous patch? Looks like it didn't get moved when I was reversing the order of the patches. Moved the change to the previous patch. > > { > > struct thread_info *tp = ecs->event_thread; > > stop_pc_sal = find_pc_line (ecs->event_thread->stop_pc (), > > 0); > > @@ -6755,7 +6766,7 @@ process_event_stop_test (struct > > execution_control_state *ecs) > > > > Return using a step range so we will keep stepping back to > > the > > first instruction in the source code line. */ > > - tp->control.step_range_start = ecs->stop_func_start; > > + tp->control.step_range_start = ecs->stop_func_alt_start; > > tp->control.step_range_end = ecs->stop_func_start; > > keep_going (ecs); > > return; > > @@ -6892,8 +6903,10 @@ process_event_stop_test (struct > > execution_control_state *ecs) > > (unless it's the function entry point, in which case > > keep going back to the call point). */ > > CORE_ADDR stop_pc = ecs->event_thread->stop_pc (); > > + > > if (stop_pc == ecs->event_thread->control.step_range_start > > - && stop_pc != ecs->stop_func_start > > + && (stop_pc < ecs->stop_func_alt_start > > + || stop_pc > ecs->stop_func_start) > > && execution_direction == EXEC_REVERSE) > > end_stepping_range (ecs); > > else > > diff --git a/gdb/testsuite/gdb.reverse/finish-reverse-next.c > > b/gdb/testsuite/gdb.reverse/finish-reverse-next.c > > index 42e41b5a2e0..55f81d2bc01 100644 > > --- a/gdb/testsuite/gdb.reverse/finish-reverse-next.c > > +++ b/gdb/testsuite/gdb.reverse/finish-reverse-next.c > > @@ -1,4 +1,4 @@ > > > > diff --git a/gdb/testsuite/gdb.reverse/finish-reverse-next.exp > > b/gdb/testsuite/gdb.reverse/finish-reverse-next.exp > > index 7880de10ffc..fbc024b48b9 100644 > > --- a/gdb/testsuite/gdb.reverse/finish-reverse-next.exp > > +++ b/gdb/testsuite/gdb.reverse/finish-reverse-next.exp The comments for patch 1/2 about using gdb_breakpoint and gdb_continue_to_breakpoint were also applied to the two new tests. > > + > > +### TEST 3: reverse finish from the alternate entry point > > instruction (GEP) in > > +### function1 when called using the alternate entry point (GEP). > > + > > +# Set breakpoint at call to funp in main. > > +set GEP_test [gdb_get_line_number "CALL VIA GEP" $srcfile] > > +gdb_test "break $srcfile:$GEP_test" "Breakpoint $decimal at .*" \ > > + "set breakpoint on function1 GEP call to stepi into function" > > + > > +# Continue to break point at funp call in main. > > +gdb_test "continue" "Breakpoint $decimal.*funp \\(a, b\\).*" \ > > + "stopped at funp entry point instruction" > > + > > +# stepi until we see "{" indicating we entered function. > > +cmd_until "stepi" "CALL VIA GEP" "{" "stepi into funp call" > > + > > +delete_breakpoints > > + > > +gdb_test "reverse-finish" ".*funp \\(a, b\\);.*" \ > > + "function1 GEP call call from GEP" > > + > > +# Check to make sure we stopped at the first instruction in the > > source code > > +# line. It should only take one reverse next command to get to > > the previous > > +# source line. If GDB stops at the last instruction in the source > > code line > > +# it will take two reverse next instructions to get to the > > previous source > > +# line. > > +gdb_test "reverse-next" ".*b = 50;.*" "reverse next at b = 50, > > call from GEP" > > + > > +# Turn off record to clear logs and turn on again > > +gdb_test "record stop" "Process record is stopped.*" \ > > + "turn off process record for test3" > > +gdb_test_no_output "record" "turn on process record for test4" > > + > > + > > +### TEST 4: reverse finish from the body of function 1 when > > calling using the > > +### alternate entrypoint (GEP). > > +gdb_test "break $srcfile:$GEP_test" "Breakpoint $decimal at .*" \ > > + "set breakpoint on funp GEP call to step into body of > > function" > > + > > +# Continue to break point at funp call. > > +gdb_test "continue" "Breakpoint $decimal,.*funp \\(a, b\\).*" \ > > + "stopped at funp call" > > + > > +# Step into body of funp, called via GEP. > > +gdb_test "step" ".*int ret = 0;.*" "step test 2" > > + > > +delete_breakpoints > > + > > +gdb_test "reverse-finish" ".*funp \\(a, b\\);.*" \ > > + "reverse-finish function1 GEP call, from function body " > > + > > +# Check to make sure we stopped at the first instruction in the > > source code > > +# line. It should only take one reverse next command to get to > > the previous > > +# source line. If GDB stops at the last instruction in the source > > code line > > +# it will take two reverse next instructions to get to the > > previous source > > +# line. > > +gdb_test "reverse-next" ".*b = 50;.*" \ > > + "reverse next at b = 50 from function body" > >