From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from gateway24.websitewelcome.com (gateway24.websitewelcome.com [192.185.51.202]) by sourceware.org (Postfix) with ESMTPS id E8B8E3871029 for ; Mon, 16 Mar 2020 20:57:31 +0000 (GMT) Received: from cm16.websitewelcome.com (cm16.websitewelcome.com [100.42.49.19]) by gateway24.websitewelcome.com (Postfix) with ESMTP id 638F61FF99 for ; Mon, 16 Mar 2020 15:57:30 -0500 (CDT) Received: from box5379.bluehost.com ([162.241.216.53]) by cmsmtp with SMTP id DwnijAYhS8vkBDwnij294u; Mon, 16 Mar 2020 15:57:30 -0500 X-Authority-Reason: nr=8 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=tromey.com; s=default; h=Content-Type:MIME-Version:Message-ID:In-Reply-To:Date: References:Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=HeC6kUd4yCEk5ZTgRSnv/SzyIMmk/S90J++SrPJ+Y2A=; b=R/2FfudSnTSWx7dQ1SoTmfiDW9 NjxPzGofsexr7Wsn9YR7bwMO4QeH+PnMW/GA3D10TLybGwYCLosdQL4oVVhtBecvm9sA+t0jSLftL Q62w7rvYLfZPm9oo9lH5yp3iI; Received: from 184-96-250-69.hlrn.qwest.net ([184.96.250.69]:54386 helo=murgatroyd) by box5379.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92) (envelope-from ) id 1jDwni-0023Cx-3h; Mon, 16 Mar 2020 14:57:30 -0600 From: Tom Tromey To: Andrew Burgess Cc: gdb-patches@sourceware.org, Bernd Edlinger Subject: Re: [PATCHv2 2/2] gdb: Add support for tracking the DWARF line table is-stmt field References: X-Attribution: Tom Date: Mon, 16 Mar 2020 14:57:29 -0600 In-Reply-To: (Andrew Burgess's message of "Sun, 8 Mar 2020 12:50:16 +0000") Message-ID: <87d09c3tmu.fsf@tromey.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - box5379.bluehost.com X-AntiAbuse: Original Domain - sourceware.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - tromey.com X-BWhitelist: no X-Source-IP: 184.96.250.69 X-Source-L: No X-Exim-ID: 1jDwni-0023Cx-3h X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: 184-96-250-69.hlrn.qwest.net (murgatroyd) [184.96.250.69]:54386 X-Source-Auth: tom+tromey.com X-Email-Count: 2 X-Source-Cap: ZWx5bnJvYmk7ZWx5bnJvYmk7Ym94NTM3OS5ibHVlaG9zdC5jb20= X-Local-Domain: yes X-Spam-Status: No, score=1.3 required=5.0 tests=DKIM_SIGNED, DKIM_VALID, JMQ_SPF_NEUTRAL, RCVD_IN_DNSWL_NONE, SPF_HELO_PASS, SPF_NEUTRAL autolearn=no autolearn_force=no version=3.4.2 X-Spam-Level: * X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org 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: , X-List-Received-Date: Mon, 16 Mar 2020 20:57:33 -0000 Hi. This particular hunk causes a regression on an internal test case for a RISC-V target: Andrew> + /* If we have a duplicate for the previous entry then ignore the new Andrew> + entry, except, if the new entry is setting the is_stmt flag, then Andrew> + ensure the previous entry respects the new setting. */ Andrew> + e = subfile->line_vector->item + subfile->line_vector->nitems - 1; Andrew> + if (e->line == line && e->pc == pc) Andrew> + { Andrew> + if (is_stmt && !e->is_stmt) Andrew> + e->is_stmt = 1; Andrew> + return; Andrew> + } Now, I'm not 100% certain that this is a "true" regression. The test case in question already has a large number of XFAILs for various targets, because in practice gdb reports different stop locations for different compilers. It's just 2 short files so I can share it here: /* r.c */ #include "r.h" int main () { callee (); } /* r.h */ int counter = 42; inline void callee () { counter = 0; /* break here */ } When I look at this with readelf I see: $ readelf --debug-dump=decodedline ./r Contents of the .debug_line section: r.c: File name Line number Starting address View Stmt r.c 6 0x80000042 x r.c 7 0x80000042 1 x r.h: r.h 6 0x80000042 2 x r.h 6 0x80000042 3 r.c: r.c 8 0x8000004a 4 r.c 8 0x8000004e 5 I can send an executable if you want. If I run gdb on the resulting program and "break r.h:6", before the is-statement patch it reports r.h:6, but afterward it says: (gdb) b r.h:6 Breakpoint 1 at 0x8000004a: file r.c, line 8. Backing out the hunk in question up above is enough to fix the problem. What is happening is that gdb is no longer recognizing the special prologue rule in skip_prologue_sal: /* For languages other than assembly, treat two consecutive line entries at the same address as a zero-instruction prologue. The GNU assembler emits separate line notes for each instruction in a multi-instruction macro, but compilers generally will not do this. */ TBH this has always seemed like a big hack, at least in the DWARF era. But, I suppose it's a hack we continue to need, at least until GCC emits proper prologue end notes. Just removing the "return" is enough to make it work for me. I didn't try a real test run, though. I'd appreciate any thoughts you have on this. thanks, Tom