From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 34127 invoked by alias); 20 Dec 2019 06:13:39 -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 34117 invoked by uid 89); 20 Dec 2019 06:13:39 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-5.6 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.1 spammy=stumbled, valuable, technique, sleep X-HELO: simark.ca Received: from simark.ca (HELO simark.ca) (158.69.221.121) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 20 Dec 2019 06:13:37 +0000 Received: from [10.0.0.11] (unknown [192.222.164.54]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPSA id 19CCB1E508; Fri, 20 Dec 2019 01:13:35 -0500 (EST) Subject: Re: [PATCH] Fix an issue with the gdb step-over aka. "n" command To: Bernd Edlinger , "gdb-patches@sourceware.org" Cc: Tom Tromey References: From: Simon Marchi Message-ID: Date: Fri, 20 Dec 2019 06:13:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-SW-Source: 2019-12/txt/msg00847.txt.bz2 Hi Bernd, On 2019-12-19 5:53 p.m., Bernd Edlinger wrote: > Does this explanation make sense? Yes. Well I think so, I have to admit this is a bit over my head, there are a lot of pieces to put together to have a good understanding of the problem. I just did a first read, I'll sleep on it and come back to it later. Thanks for the small reproducer, this is extremely valuable. I think it will be a good idea to integrate it as a test case in the test suite. In your patch to dwarf2read.c, I was a bit surprised to see: m_last_subfile != m_cu->get_builder ()->get_current_subfile () So your fix only works if the inlined subroutine comes from another file? If I move the tree_check function in next-inline.cc, the fix no longer applies, and we get the broken behavior. From your previous email, I understand that this is expected. I guess that if both are in the same file, we can't detect this situation using the same technique. I also read about location views, since that's what Alexandre referred to. It sounds like it's a magic solution that will allow GDB to do the right thing in this kind of situation. If that's indeed the case, then it might be good to start exploring this path. I'd like to have a better understanding of how this will help GDB make a smarter "next", and what kind of effort is needed to make GDB use it. My understanding is that location views allow having an address mapped to multiple source locations. For example, here's the problematic address in the next-inline test case I've compiled: ./next-inline.h:[++] next-inline.h 28 0x1175 x next-inline.h 30 0x1175 1 x ./next-inline.cc:[++] next-inline.cc 22 0x1175 2 Today, when I ask GDB "which source line does this address correspond to", it gives me one answer. Does this mean that GDB will now say that 0x1175 corresponds to - next-inline.h:28 - next-inline.h:30 - next-inline.cc:22 all at the same time? Is one of these source locations more important than the others? If execution happens to stop exactly at this address, which location do we present to the user? And to come back the problem at hand, how does this help GDB make a smarter "next"? Btw, I stumbled on a bug with the TUI source display. It might be caused by this patch, or it might be that this patch uncovers it. When I do these actions: - Start GDB with the next-inline test file (from this patch) - Enable the TUI - Type "start" - Type "s" - Type "n" twice The TUI source display wrongfully jumps to the header file, line 24. When I type "frame", it says I'm stopped at next-line.cc:24. So it is showing the right line number of the wrong file. Thanks, Simon