From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from eggs.gnu.org (eggs.gnu.org [IPv6:2001:470:142:3::10]) by sourceware.org (Postfix) with ESMTPS id BC6EB3858CDB for ; Wed, 24 May 2023 11:14:09 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org BC6EB3858CDB Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gnu.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gnu.org Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1q1mRV-0003r4-8W; Wed, 24 May 2023 07:14:09 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=W4OwZ/J4KBOBo5PIyIg3xMsWi6OR7NeoXstn9tROwmM=; b=dbS+63Nls75f WdGaBBufm3TrawoBzWxLEt/CLUgyCVLJqfTJqGsysmkII6QVbqXmlZAdwyHc83NozsN70RtKxPoun hr/g3edhl//jNsflkET7j/HBvQEiHEfGItnCl3DpE1SjDCc2+Q01MxZOb1cRHp413ymn4EjIrRCK+ HzWwkWsy2nwIYgLT5TbQ9QDc9aNNCllzmc+19a5NIS1tbGuzBFIbHx+R57Efi/NMQW9UQgJuetdR1 4FUcmPX53kBhlCeGvTDYw1z8wSn3zXsLbTI5glHWeYlchv2Am+FRjXFslvDZTXMpvlPC1hJj8Y9od ZYelUpwma+2pzr5qi51KgQ==; Received: from [87.69.77.57] (helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1q1mRU-0004Y4-OY; Wed, 24 May 2023 07:14:09 -0400 Date: Wed, 24 May 2023 14:14:35 +0300 Message-Id: <83fs7mnfqc.fsf@gnu.org> From: Eli Zaretskii To: Simon Farre Cc: gdb-patches@sourceware.org In-Reply-To: (message from Simon Farre on Wed, 24 May 2023 10:18:33 +0200) Subject: Re: [PATCH v1] [gdb/infcmd]: Add next-expression command References: <20230516094711.57265-1-simon.farre.cx@gmail.com> <83v8gsz4mm.fsf@gnu.org> <83v8gpvp0j.fsf@gnu.org> X-Spam-Status: No, score=1.7 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_BARRACUDACENTRAL,SPF_HELO_PASS,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6 X-Spam-Level: * X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: > Date: Wed, 24 May 2023 10:18:33 +0200 > Cc: gdb-patches@sourceware.org > From: Simon Farre > > The "source-level" part is clear, but what about "stepping to > columns"? The command steps by expressions, not by columns. > > Well, the column metadata is essentially emitted for expressions and statements (or "logical > breakpoint locations"), but the actual meta data that is recorded is by column (and a statement flag), > so we can't really be _entirely_ sure that what we're stepping to is an expression or statement, even > though that is what it's intended to represent. Which is why I used column and expression > interchangeably. AFAIU, the fact that the metadata is defined in terms of columns is an implementation detail of no particular interest to GDB users. On the user level, this is supposed to step by expressions, is that right? Perhaps, to avoid too many miscommunications, you could point me to the relevant description in the DWARF2 spec, so I could read it, and then we could talk based on the same information? > Perhaps further explanation is required here, or possibly even renaming the feature to `next-column` > and `step-column` for the two variants that I've implemented; where the `step` variant behaves similarly > to what the normal step/next counterparts do; i.e. if there's an inline frame on the same source file (like > a lambda or callback) then step will step into it, whereas next will step over it. The 2 variants will be in > the upcoming v3. OK, but I think we still need to understand better the purpose of the feature, and specifically what kind of information the DWARF2 data is supposed to provide here. > There's no need for too much detail, if this is an old feature. Just > say something like > > The support for expressions was added to DWARF2 30 years ago, so any > compiler which emits DWARF2 debug info should nowadays produce the > information required by this command. E.g., GCC supports this since > version . > > (Assuming it is true that every compiler released reasonably recently > will produce this as part of DWARF debug info.) > > Right, I've only tested with the latest, but I'm pretty sure that the last 4-5 years of compilers at least emit > column meta data. I've tested gcc-12, clang-14 and the latest rustc compiler (I know rustc has emitted > it for at _least_ 5 years). I'm building gcc-8 (5+ years) as I write this and will test that. Where in the > manual would you like me to put the above paragraph? Together with the documentation of the > command or somewhere else? And the same question goes for > > We need to explain in the manual that the "columns" actually are (or > are likely to be) byte offsets from the beginning of the source line. Both should be explained where these new commands are described, because that is needed to fully understand what the commands do and how to use them.