From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr1-f68.google.com (mail-wr1-f68.google.com [209.85.221.68]) by sourceware.org (Postfix) with ESMTPS id D9F813857C61 for ; Fri, 24 Jul 2020 11:26:13 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org D9F813857C61 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=palves.net Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=alves.ped@gmail.com Received: by mail-wr1-f68.google.com with SMTP id a14so7989041wra.5 for ; Fri, 24 Jul 2020 04:26:13 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=5a78rCQ/y1KdI/a/S1Vb+zEFLzRuHU/WryQYzqCxc90=; b=jEH0bXcDdrKuiYcUi10eHHxtJAJOsBnnmnxVpX+tcQmGzA4nHF+Yv2n8TcM7Fxw8i+ lhzw7LW63g05S0i3F22YiEKEtQ4BaoXCoJMwVivS/8zAGyG3eLwF3sE66wYKgsI/IA7U F8ZEsBIe0WN/sE8gVC2F6MrOX9lSdanFkrLOvjqsnhTcVGhdziiCvCQcX5LD+TsTdis2 +tIy+C/q19NZvjSoP5WSoZlLcyHjoi69fYaYFxUneAXaFN8/W0V9nWwGw6skVwtZWWfk 6n+DM/+lcul21a+hyV/SUnvCEz0CGXlcr/qFF3igNZM1HmGHn7BVn6O2HJNzrljdhDSi Ve0A== X-Gm-Message-State: AOAM531WVbkuDvLS7nlCTjmlzSe07gkKEK99VravWRIarbkl5FwqfSYX 14gDKeLrU6tOO63V5DwNaOBtGRxCU2Y= X-Google-Smtp-Source: ABdhPJxeHSpZ5iGuyWIHC1rYn/6YZ6ee82PyMmbArbMgQ9UL7x4o/pRsppBDB/lKYJMleuuhb9JIsg== X-Received: by 2002:adf:e801:: with SMTP id o1mr8399003wrm.54.1595589971761; Fri, 24 Jul 2020 04:26:11 -0700 (PDT) Received: from ?IPv6:2001:8a0:f91a:c400:56ee:75ff:fe8d:232b? ([2001:8a0:f91a:c400:56ee:75ff:fe8d:232b]) by smtp.gmail.com with ESMTPSA id o7sm942100wrv.50.2020.07.24.04.26.10 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 24 Jul 2020 04:26:10 -0700 (PDT) Subject: Re: [PATCH 0/2] Handle "line 0" ranges (PR26243, PR15314, PR15668) To: Simon Marchi , gdb-patches@sourceware.org References: <20200721153737.11262-1-pedro@palves.net> <3c779fff-3bb5-db0e-e140-9cfca8366696@simark.ca> From: Pedro Alves Message-ID: <3947b419-9c61-e92f-6095-0d08129e8cc1@palves.net> Date: Fri, 24 Jul 2020 12:26:07 +0100 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: <3c779fff-3bb5-db0e-e140-9cfca8366696@simark.ca> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-3.7 required=5.0 tests=BAYES_00, FREEMAIL_FORGED_FROMDOMAIN, FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS, KAM_DMARC_STATUS, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H2, 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: Fri, 24 Jul 2020 11:26:15 -0000 On 7/21/20 4:48 PM, Simon Marchi wrote: > On 2020-07-21 11:37 a.m., Pedro Alves wrote: >> PR 26243 shows that Clang associates some instructions in the middle >> of functions to line 0. That is valid DWARF, but it wasn't noticed >> until recently, when the line info reading code was tweaked. >> Currently, "step" and "next" with Clang misbehave because these "line >> 0" instructions or instruction ranges aren't being handled. >> >> This series fixes that in two parts: >> >> #1 - By teaching infrun to step over such no-line-info instructions >> automatically, when "set step-mode" is "off" (which is the >> default). >> >> #2 - By making "step" and "next" behave like "stepi" and "nexti" >> respectively when a step is started at an instruction with no >> line info. >> >> I think that with the first patch, most users won't frequently notice >> these "no line info" regions unless they use stepi to run to them, or >> they set a breapoint by address in them. But it can happen that you >> stop in one of them, and I think that making "step" not step out of >> the whole function is just a good idea if it does happen. The second >> patch also fixes the older PR15314 and PR15668, because the error in >> question they are complaining about is removed by that patch. >> >> I think we could also try to fix the issue addressed by #2 by making a >> "step" started at an instruction with no line info step until it finds >> an instruction with line info (maybe in the same function, maybe in a >> different function), instead of stepping out of the current function. >> I do think that the behavior I'm proposing is more intuitive, though. >> >> Pedro Alves (2): >> Keep stepping over "line 0" ranges (PR 26243) >> Make step act as stepi if no line info (PR26243, PR15314, PR15668) >> >> gdb/doc/gdb.texinfo | 36 ++-- >> gdb/NEWS | 5 + >> gdb/infcmd.c | 30 +-- >> gdb/infrun.c | 47 +++-- >> gdb/testsuite/gdb.base/step-symless.exp | 20 +- >> gdb/testsuite/gdb.dwarf2/dw2-line-number-zero.c | 61 ++++++ >> gdb/testsuite/gdb.dwarf2/dw2-line-number-zero.exp | 240 ++++++++++++++++++++++ >> 7 files changed, 383 insertions(+), 56 deletions(-) >> create mode 100644 gdb/testsuite/gdb.dwarf2/dw2-line-number-zero.c >> create mode 100644 gdb/testsuite/gdb.dwarf2/dw2-line-number-zero.exp >> >> >> base-commit: 6d3d6e4ba779dc08b134cd1a09b055dbd88dbf8a >> -- >> 2.14.5 >> > > Because it can affect what kind of other bugfixes and mitigation we do > and how this patchset is discussed, my first question is: do you suggest > merging these patches before the GDB 10 branch is created or waiting > after the branch? At this point, I think it would be safer to go with Vries' approach for GDB 10. Also, I will be out of office the whole of next week, so I wouldn't be around to handle any fallout. Also, I'm going to use a GDB with patch #2 from this series for all my debugging for a while, see how will it holds up in practice. Thanks, Pedro Alves