From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm1-x342.google.com (mail-wm1-x342.google.com [IPv6:2a00:1450:4864:20::342]) by sourceware.org (Postfix) with ESMTPS id 817C8386F830 for ; Mon, 27 Apr 2020 10:34:21 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 817C8386F830 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=embecosm.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=andrew.burgess@embecosm.com Received: by mail-wm1-x342.google.com with SMTP id r26so19867292wmh.0 for ; Mon, 27 Apr 2020 03:34:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=embecosm.com; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=2yyAHTVUEvuDe3mAzxikSdPFrsGnAEGzds1BoJG0eg0=; b=Kp1ZkEgbGpXS7vtf0LE39tBxj08MNDYbHvm1kjNupsBz+ljITwUYZD4FzlJm42Tfd4 8n78SDUb4iTb5f4GGM/LI3zH0YO0RDCoK1y93m5IR+gUMyAG77GotCsNRiF/n7u5gZUU S0HngSthhjjjlt0PgreRuM14QjL1XXpAjCNt6KWyvMfqgsCYXwkTYrBAjqohimEvJMle fP4T5rjcK6W1KL1AwhWEZc0CMAynVENTd3sL7jN9CxVTnxaWrDboVKfpR0edQBFzdsBE vu06sYTNDhsasNqxfRPGUO4RuXBcxKs0WhOBBAjb4EkhzfP1MgzJb+IR9hQNconc0boz 4vsw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=2yyAHTVUEvuDe3mAzxikSdPFrsGnAEGzds1BoJG0eg0=; b=U/P32huLI8WhkqSfg18Ln3BMS26QUOs8JeHjm6EcnSEaoFU/yfRbNNRTgUKRtmO4U6 rXt2sgzHsc2XF6KpWU3mYg1v0K7VencNvjDrmKkBBI7xHibKUxLsQ8P/Jg3xYkMyMDOO HJrIbSbJrMWsYJbmnFdTPlZ7sOcljKq+C0WmqaXSuzfRQOhYuL32Xf+AJprRi6Ep0b/K 9PyMQFMQXKonbtGeO9odSDt2Ags+wCZyuWgsGXWO48UTG7MWU3o7JyeuQzK84I6oBjjB BhpN98SYde+zBY+mNPrPjo0CDAPWut5BZFnCxNtXzOZzTyAReizw+XpTMtzIUtLeWdGG ND5g== X-Gm-Message-State: AGi0PuZm7Si68aa3YpNlKU3+YOpbZK8DaXhwhSYIxPNMqkkAMc3WcyXO gjC1uRgYBz7WVdNDf2sukRB6MA== X-Google-Smtp-Source: APiQypL+RZmo+SP1t6qhc3K6odYUR/rKIX0MIOqure9tqqQO6QbDaUX3S1JUvUxhGpeDyOmetBsIxg== X-Received: by 2002:a7b:c84f:: with SMTP id c15mr24047132wml.166.1587983660424; Mon, 27 Apr 2020 03:34:20 -0700 (PDT) Received: from localhost (host81-151-181-184.range81-151.btcentralplus.com. [81.151.181.184]) by smtp.gmail.com with ESMTPSA id t16sm21088972wrb.8.2020.04.27.03.34.18 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 27 Apr 2020 03:34:19 -0700 (PDT) Date: Mon, 27 Apr 2020 11:34:18 +0100 From: Andrew Burgess To: Bernd Edlinger Cc: Tom Tromey , gdb-patches@sourceware.org, Alexandre Oliva Subject: Re: [PATCH 2/2] gdb: Preserve is-stmt lines when switch between files Message-ID: <20200427103418.GF3522@embecosm.com> References: <6e9b21a0002164cec014dfe4d94d816a376989b4.1585952198.git.andrew.burgess@embecosm.com> <20200414112841.GC2366@embecosm.com> <20200416171809.GJ2366@embecosm.com> <87lfmnql4g.fsf@tromey.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Operating-System: Linux/5.5.17-200.fc31.x86_64 (x86_64) X-Uptime: 10:48:45 up 6 days, 18:37, X-Editor: GNU Emacs [ http://www.gnu.org/software/emacs ] X-Spam-Status: No, score=-11.6 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, KAM_SHORT, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 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, 27 Apr 2020 10:34:25 -0000 * Bernd Edlinger [2020-04-25 09:06:35 +0200]: > CC Alexandre Oliva, who maintains this part of GCC. > > > On 4/22/20 11:13 PM, Tom Tromey wrote: > >>>>>> "Andrew" == Andrew Burgess writes: > > > > I read through the various threads on this topic, though I think maybe > > not very well. > > > > IIUC, the issue at hand is that there are two proposed patches to fix > > various issues in this area. > > > > > > Andrew's patch takes us roughly to the status quo from before is-stmt > > landed. This patch takes the view that GCC is currently buggy, so one > > test is partly disabled; and there's a new bug so we can fix GDB once > > GCC is fixed. > > > > Bernd's patch takes the view that GCC won't be fixed and tries to work > > around the problem; it drops at least one "FILE:LINE" case that > > currently works. > > > > > > Is that a fair summary? There were many messages and details, so I'm > > not sure I either understood it all or that it can be summarized like > > this. > > > > Yes, I agree with this summary. > > > If that's fair, then my inclination is to move forward with Andrew's > > patch for the time being, with the primary justification being > > conservatism. Bernd's patch can always land if/when we have some > > clarification from GCC about whether the bugs there will be fixed. > > > > Let me know what you think. > > > > I think if we take Andrew's patch the only possible outcome > will be that gcc will disable that statement frontiers debug > option by default, because they do not understand what we > want from them. (I am one of them, but I came here to understand > you better) I tried to describe the two current issues I see with GCC in this bug report[1] but after a stupid mistake by me of using an older version of binutils the conversation got side-tracked into a discussion about view numbers and GDB. It is my position that neither of the bugs described in [1] require view number changes, nor additional DWARF features, they could be fixed entirely withing GCC (in theory at least). I'm not entirely sure which bit of debug statement frontiers is responsible for. After reading one of your other email[2], in which you said this bug was present from GCC-7 I went and ran some tests, as I thought gdb.cp/step-and-next-inline.exp doesn't run on GCC-7 as GCC that old doesn't support -gstatement-frontiers. I was right, that flag doesn't exist on GCC-7, and your were correct that some of the range bugs (at least) do still exist on GCC-7. After reading[2] I'd also be interest to understand what flaw in DWARF you feel makes a difference in this case. Given some of your feedback in [1] I think that you might be talking about improvements (the addition of?) to the view number support, but while I agree with you that this might (would?) allow for improved debug experience, I don't think it would be needed in order for GCC to do better in this case. I think it is great Bernd, that you are reaching out from the GCC community to engage with GDB, this is certainly the best way to ensure that we can work together as communities to give the best possible debug experience, and I'm sorry you feel that I have not been clear enough about the issues I'm seeing here. I do still think that merging my patch is the correct way to move forward, however, I don't think the future has to be as bleak as you describe above. I am happy to continue discussing this issue for as long as you are in order to try and find a solution that makes everyone happy. That said, here's what I think would need to happen so that _I_ (personally) was happy to accept your patch: 1. We need to agree what we're working around. In [2] you describe this issue as a flaw in DWARF, while in [1] I describe this as an issue in GCC. I think we need to first need to agree on what the spec says, what GCC can (currently) do in an ideal world, and what GCC can be expected to do (currently) in the real world. 2. We should change GDB assuming that any bugs in GCC or DWARF will one day be fixed, and that when that happens we would, ideally, not have to apply the work around. So fixes should be guarded with a check of either the producer or the DWARF version. 3. Currently (to me) it appears that we are crafting a work around based on one test case (gdb.cp/step-and-next-inline.exp). My concern here is that when we talk about changing the line table, or range handling, these are pretty core aspects of GDB. As a GCC developer you probably have more insight, but it doesn't feel clear to me yet, do we know that GCC always misbehaves in the same say across all, or most, compiled code? I don't know how we address this without merging your patch, releasing GDB and seeing how it works in the wild. However, if we did decide to "just try it", I would still prefer we staged things as: (a) Merge my patch, targeted regression fix, then (b) Your patch, new functionality GCC/DWARF ranges work around. In this way, if we end up backing out some or all of (b) we still have (a) in place that fixes the regression. I'm more than happy for a rebase of (b) in include full removal of (a). Thanks for your continued input. Andrew [1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94474 [2] https://sourceware.org/pipermail/gdb-patches/2020-April/167933.html