From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id 55QdH/debGA1TgAAWB0awg (envelope-from ) for ; Tue, 06 Apr 2021 09:15:35 -0400 Received: by simark.ca (Postfix, from userid 112) id 768881E939; Tue, 6 Apr 2021 09:15:35 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-1.0 required=5.0 tests=MAILING_LIST_MULTI, URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.2 Received: from sourceware.org (server2.sourceware.org [8.43.85.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id 7E7151E54D for ; Tue, 6 Apr 2021 09:15:34 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 2D22A3846078; Tue, 6 Apr 2021 13:15:34 +0000 (GMT) Received: from mx2.suse.de (mx2.suse.de [195.135.220.15]) by sourceware.org (Postfix) with ESMTPS id 1B0E63846078 for ; Tue, 6 Apr 2021 13:15:31 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 1B0E63846078 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=suse.de Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=tdevries@suse.de X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id 2320CB1AB for ; Tue, 6 Apr 2021 13:15:30 +0000 (UTC) Subject: [committed][gdb/breakpoints] Workaround missing line-table entry From: Tom de Vries To: gdb-patches@sourceware.org References: <20210122091509.GA30312@delia> <22fce456-c018-649f-2d20-9d950dc6062a@suse.de> <38281254-82de-1e7d-bf38-c00ecf62fbd9@suse.de> Message-ID: Date: Tue, 6 Apr 2021 15:15:29 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.8.0 MIME-Version: 1.0 In-Reply-To: <38281254-82de-1e7d-bf38-c00ecf62fbd9@suse.de> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: gdb-patches-bounces@sourceware.org Sender: "Gdb-patches" On 3/5/21 7:35 AM, Tom de Vries wrote: > On 2/5/21 11:07 AM, Tom de Vries wrote: >> On 1/22/21 10:15 AM, Tom de Vries wrote: >>> Hi, >>> >>> When running test-case gdb.opt/inline-cmds.exp, we run into this KFAIL with >>> gcc: >>> ... >>> Breakpoint 7, main () at gdb.opt/inline-cmds.c:71^M >>> 71 result = 0; /* set breakpoint 3 here */^M >>> (gdb) PASS: gdb.opt/inline-cmds.exp: continue to breakpoint: consecutive func1 >>> next^M >>> 73 func1 (); /* first call */^M >>> (gdb) PASS: gdb.opt/inline-cmds.exp: next to first func1 >>> next^M >>> 75 marker ();^M >>> (gdb) KFAIL: gdb.opt/inline-cmds.exp: next to second func1 (PRMS: gdb/25884) >>> ... >>> while with clang we have instead: >>> ... >>> next^M >>> 74 func1 (); /* second call */^M >>> (gdb) PASS: gdb.opt/inline-cmds.exp: next to second func1 >>> ... >>> >>> The relevant bit of the test source is here in inline-cmds.c: >>> ... >>> 71 result = 0; /* set breakpoint 3 here */ >>> 72 >>> 73 func1 (); /* first call */ >>> 74 func1 (); /* second call */ >>> 75 marker (); >>> ... >>> with func1 defined as: >>> ... >>> 33 inline __attribute__((always_inline)) int func1(void) >>> 34 { >>> 35 bar (); >>> 36 return x * y; >>> 37 } >>> ... >>> >>> The corresponding insns are: >>> ... >>> 40050b: movl $0x0,0x200b1f(%rip) # 601034 >>> 400515: callq 40057b >>> 40051a: callq 40057b >>> 40051f: callq 400596 >>> ... >>> and the line number info is: >>> ... >>> Line number Starting address View Stmt >>> 71 0x40050b x >>> 35 0x400515 x >>> 75 0x40051f x >>> ... >>> >>> The line number info is missing an entry for the insn at 40051a, and that is >>> causing the FAIL. This is a gcc issue, filed as PR gcc/98780 -" Missing line >>> table entry for inlined stmt at -g -O0". >>> >>> [ For contrast, with clang we have an extra entry: >>> ... >>> Line number Starting address View Stmt >>> 71 0x40050b x >>> 35 0x400515 x >>> 35 0x40051a >>> 75 0x40051f x >>> ... >>> though it appears to be missing the start-of-statement marker. ] >>> >>> However, there is debug info that indicates that the insn at 40051a is not >>> part of the line table entry for the insn at 400515: >>> ... >>> <2><1c4>: Abbrev Number: 8 (DW_TAG_inlined_subroutine) >>> <1c5> DW_AT_abstract_origin: <0x2a2> >>> <1c9> DW_AT_low_pc : 0x400515 >>> <1d1> DW_AT_high_pc : 0x5 >>> <1d9> DW_AT_call_file : 1 >>> <1da> DW_AT_call_line : 73 >>> <2><1db>: Abbrev Number: 8 (DW_TAG_inlined_subroutine) >>> <1dc> DW_AT_abstract_origin: <0x2a2> >>> <1e0> DW_AT_low_pc : 0x40051a >>> <1e8> DW_AT_high_pc : 0x5 >>> <1f0> DW_AT_call_file : 1 >>> <1f1> DW_AT_call_line : 74 >>> ... >>> and indeed lldb manages to "next" from line 73 to line 74. >>> >>> Work around the missing line table entry, by using the inline frame info to >>> narrow the stepping range in prepare_one_step. >>> >>> Tested on x86_64-linux. >>> >>> Any comments? >>> > > Ping. > Well, let's commit then :) Thanks, - Tom >>> [gdb/breakpoints] Workaround missing line-table entry >>> >>> gdb/ChangeLog: >>> >>> 2021-01-22 Tom de Vries >>> >>> PR breakpoints/25884 >>> * infcmd.c (prepare_one_step): Using inline frame info to narrow >>> stepping range. >>> >>> gdb/testsuite/ChangeLog: >>> >>> 2021-01-22 Tom de Vries >>> >>> PR breakpoints/25884 >>> * gdb.opt/inline-cmds.exp: Remove kfail. >>> >>> --- >>> gdb/infcmd.c | 14 ++++++++++++++ >>> gdb/testsuite/gdb.opt/inline-cmds.exp | 17 +---------------- >>> 2 files changed, 15 insertions(+), 16 deletions(-) >>> >>> diff --git a/gdb/infcmd.c b/gdb/infcmd.c >>> index 6f0ed952de6..ecb3de31879 100644 >>> --- a/gdb/infcmd.c >>> +++ b/gdb/infcmd.c >>> @@ -1009,6 +1009,20 @@ prepare_one_step (thread_info *tp, struct step_command_fsm *sm) >>> &tp->control.step_range_start, >>> &tp->control.step_range_end); >>> >>> + /* There's a problem in gcc (PR gcc/98780) that causes missing line >>> + table entries, which results in a too large stepping range. >>> + Use inlined_subroutine info to make the range more narrow. */ >>> + if (inline_skipped_frames (tp) > 0) >>> + { >>> + symbol *sym = inline_skipped_symbol (tp); >>> + if (SYMBOL_CLASS (sym) == LOC_BLOCK) >>> + { >>> + const block *block = SYMBOL_BLOCK_VALUE (sym); >>> + if (BLOCK_END (block) < tp->control.step_range_end) >>> + tp->control.step_range_end = BLOCK_END (block); >>> + } >>> + } >>> + >>> tp->control.may_range_step = 1; >>> >>> /* If we have no line info, switch to stepi mode. */ >>> diff --git a/gdb/testsuite/gdb.opt/inline-cmds.exp b/gdb/testsuite/gdb.opt/inline-cmds.exp >>> index 17720c46795..981dcbb4a29 100644 >>> --- a/gdb/testsuite/gdb.opt/inline-cmds.exp >>> +++ b/gdb/testsuite/gdb.opt/inline-cmds.exp >>> @@ -222,22 +222,7 @@ gdb_breakpoint $line3 >>> gdb_continue_to_breakpoint "consecutive func1" >>> >>> gdb_test "next" ".*func1 .*first call.*" "next to first func1" >>> -set msg "next to second func1" >>> -gdb_test_multiple "next" $msg { >>> - -re ".*func1 .*second call.*$gdb_prompt $" { >>> - pass $msg >>> - } >>> - -re ".*marker .*$gdb_prompt $" { >>> - # This assembles to two consecutive call instructions. >>> - # Both appear to be at the same line, because they're >>> - # in the body of the same inlined function. This is >>> - # reasonable for the line table. GDB should take the >>> - # containing block and/or function into account when >>> - # deciding how far to step. The single line table entry >>> - # is actually two consecutive instances of the same line. >>> - kfail gdb/25884 $msg >>> - } >>> -} >>> +gdb_test "next" ".*func1 .*second call.*" "next to second func1" >>> >>> # It is easier when the two inlined functions are not on the same line. >>> set line4 [gdb_get_line_number "set breakpoint 4 here"] >>>