From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5543 invoked by alias); 24 Jun 2019 19:16:40 -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 5535 invoked by uid 89); 24 Jun 2019 19:16:40 -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 autolearn=ham version=3.3.1 spammy=9864, 2011 X-HELO: mail-wr1-f65.google.com Received: from mail-wr1-f65.google.com (HELO mail-wr1-f65.google.com) (209.85.221.65) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 24 Jun 2019 19:16:39 +0000 Received: by mail-wr1-f65.google.com with SMTP id p11so15089528wre.7 for ; Mon, 24 Jun 2019 12:16:39 -0700 (PDT) Return-Path: Received: from ?IPv6:2001:8a0:f913:f700:56ee:75ff:fe8d:232b? ([2001:8a0:f913:f700:56ee:75ff:fe8d:232b]) by smtp.gmail.com with ESMTPSA id z25sm300010wmf.38.2019.06.24.12.16.36 (version=TLS1_3 cipher=AEAD-AES128-GCM-SHA256 bits=128/128); Mon, 24 Jun 2019 12:16:36 -0700 (PDT) Subject: Re: [PATCH] gdb: Don't skip prologue for explicit line breakpoints in assembler To: Andrew Burgess References: <20190612123403.14348-1-andrew.burgess@embecosm.com> <20190619181147.69974f43@f29-4.lan> <20190620205759.GI23204@embecosm.com> <20190620232314.GJ23204@embecosm.com> <406d910b-8b63-1e93-d340-7e9ab841ad0b@redhat.com> <20190622110558.GK23204@embecosm.com> <20190622112333.GL23204@embecosm.com> Cc: Kevin Buettner , gdb-patches@sourceware.org From: Pedro Alves Message-ID: <1a421f8d-069b-fbd6-4a56-2464dd3e5a15@redhat.com> Date: Mon, 24 Jun 2019 19:16:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: <20190622112333.GL23204@embecosm.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-SW-Source: 2019-06/txt/msg00557.txt.bz2 On 6/22/19 12:23 PM, Andrew Burgess wrote: >> The problem seems to be that when the explicit_line flag was first >> added there was just function for decoding linespec line numbers >> 'decode_all_digits'. At some point in time this split into >> decode_digits_ordinary and decode_digits_list_mode, when this happened >> the explicit_line flag was only ever being set in one path. >> >> I suspect that if the behaviour you discussed above ever existed, then >> it was before the split in how digits were decoded. I'm like, 98.64% sure older gdbs behave like that. But I can't rule out misremembering without trying an old gdb, which I don't have built handy at the moment either. >> >> I'm running out of time to investigate this today, but when I get some >> more time I'll dig a little more on this line of enquiry to see if I >> can confirm or deny the above theory. > > The decode_all_digits function split into decode_digits_ordinary and > decode_digits_list_mode with commit f8eba3c61629b3c03a back in Dec > 2011, I suspect that the behaviour you recall would have stopped > working then. Though I haven't confirmed this (building such old > versions of GDB is time consuming). Indeed. > > Related to what we're discussing seems to be commit a9e408182d2faaed5 > from Jan 2018, where we appear to double down on having the breakpoint > file and line update to reflect where the breakpoint was placed, not > where the breakpoint ended up. Indeed. Thanks for digging that up. > > The question then would be if we can confirm GDB did used to behave > the way you recall some time ago, do we want to go back to that > behaviour now? No, I don't think we want to go back. I've thought for a few years that "info breakpoints" should show BOTH the canonical spec behind each breakpoint, and the actual location(s) where the breakpoint is inserted. It wouldn't be that hard, even. I cooked up a prototype patch for that. I'll post it as a follow up. > And is that a blocker for my change going in? Yes if > we did want to go back to the old behaviour then part of my patch > would probably end up being reverted - as I suspect would > a9e408182d2faaed5. I'm happy to keep digging on this to see if I can > confirm if/when the behaviour changed if that helps bring clarity to > this issue. Thanks, Pedro Alves