From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20130 invoked by alias); 6 Feb 2020 09:01:06 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 19781 invoked by uid 89); 6 Feb 2020 09:00:49 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.1 spammy= X-HELO: mail-wm1-f68.google.com Received: from mail-wm1-f68.google.com (HELO mail-wm1-f68.google.com) (209.85.128.68) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 06 Feb 2020 09:00:47 +0000 Received: by mail-wm1-f68.google.com with SMTP id s144so385938wme.1 for ; Thu, 06 Feb 2020 01:00:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=hV72uC+UWpHfowhy3klvTiI4NqzMm7t8Zfw3csT4KjU=; b=hb7+I2xoSkYz4S1p+asMxMm6qWsGclAD0lrz1fozbGl+hCfd6qHdjdSRYl6BuA0qsu mFJOu2aXM4kp19ZBilCJXu5G/NJvcvnjOMT6S00Dd6cY2KSyWDdS1YiUKoQTApC2gdYU C4FyfrDeLImkFl62+7KrS+vPuslDCQuobEimet5WnMGeLffj0dVCCv+gAGz4VP4rObYh pxJxJEU75RUpxP22UZZWI2nWSBD/Yb/uR5bDOiN0iiayKxc/zpx0A64OhmT/Ep/cJeDW H9x4L+j/MZIBusA/V2jXjLlZQGe4/8U7WdYhv0d2oDMu64k/vFR+sZYIVQ5OtVDiFYkC r+rA== Return-Path: Received: from [10.10.0.24] ([94.107.206.26]) by smtp.gmail.com with ESMTPSA id o187sm2996323wme.36.2020.02.06.01.00.29 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 06 Feb 2020 01:00:29 -0800 (PST) Subject: Re: [PATCH 2/2] gdb: Add support for tracking the DWARF line table is-stmt field To: Andrew Burgess , gdb-patches@sourceware.org Cc: Bernd Edlinger References: <94e33268f64060fc887670f4ee5ed524050cbcc7.1580902412.git.andrew.burgess@embecosm.com> From: Luis Machado Message-ID: Date: Thu, 06 Feb 2020 09:01:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1 MIME-Version: 1.0 In-Reply-To: <94e33268f64060fc887670f4ee5ed524050cbcc7.1580902412.git.andrew.burgess@embecosm.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2020-02/txt/msg00125.txt.bz2 Hi, I still need to check the patch itself, but i had a question about one particular paragraph... On 2/5/20 8:37 AM, Andrew Burgess wrote: > This commit brings support for the DWARF line table is_stmt field to > GDB. The is_stmt field is used by the compiler when a single source > line is split into multiple assembler instructions, especially if the > assembler instructions are interleaved with instruction from other > source lines. > > The compiler will set the is_stmt flag false from some instructions > from the source lines, these instructions are not a good place to > insert a breakpoint in order to stop at the source line. > Instructions which are marked with the is_stmt flag true are a good > place to insert a breakpoint for that source line. > > Currently GDB ignores all instructions for which is_stmt is false. > This is fine in a lot of cases, however, there are some cases where > this means the debug experience is not as good as it could be. > > Consider stopping at a random instruction, currently this instruction > will be attributed to the last line table entry before this point for > which is_stmt was true - as these are the only line table entries that > GDB tracks. This can easily be incorrect in code with even a low > level of optimisation. > > With is_stmt tracking in place, when stopping at a random instruction > we now attribute the instruction back to the real source line, even > when is_stmt is false for that instruction in the line table. > > When inserting breakpoints we still select line table entries for > which is_stmt is true, so the breakpoint placing behaviour should not > change. > > When stepping though code (at the line level, not the instruction > level) we will still stop at instruction where is_stmt is true, I > think this is more likely to be the desired behaviour. Considering a block of continuous instructions that map to the same source line, will line-stepping stop at each one of these instructions if is_stmt is true? As opposed to stepping over the the whole block until we see a line change? I'm wondering if this would help this bug (https://sourceware.org/bugzilla/show_bug.cgi?id=21221) in any way.