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 D705A3858CDB for ; Thu, 18 May 2023 11:48:32 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org D705A3858CDB 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 1pzc7U-0004WR-Ba; Thu, 18 May 2023 07:48:32 -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=yI/lrPN3Qb46Dh+QXd3Os36dvDxdCO3in53w3l4Ukp4=; b=iImr209cmD7x Y0fFjZT6ga266SzJifNkgCb3lTlm5wo/N5ZWqMfXBOABPPtBHeIznvnALkl5y01UjCI+L1D7iUp88 etUUkm9HxzO6CfOFdoJTdq3fSoka4WtY10PtL8G/bQed/2BD4pk1eF/UFsRBhw6yakXaWxachMdGt fCdpQaziJzt0WE/d05KREwt8Ail8+YTSWEpnNTGW4kztjW0HTptjYNYCMztJt0B8piGDIvWlNXr5M /F5+DKKf7zKf2wVFB7C0Bz0nIBJEsALnYcsE+4Y4nMKP/qbuLkoQ4ZI6xAZ1aqBUuIzyqdDv+WTV6 ms4SaT2MBM9mmKZQPDWIDQ==; 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 1pzc7T-0001Nn-HG; Thu, 18 May 2023 07:48:31 -0400 Date: Thu, 18 May 2023 14:48:44 +0300 Message-Id: <83v8gpvp0j.fsf@gnu.org> From: Eli Zaretskii To: Simon Farre Cc: gdb-patches@sourceware.org In-Reply-To: (message from Simon Farre on Thu, 18 May 2023 13:12:23 +0200) Subject: Re: [PATCH v1] [gdb/infcmd]: Add next-expression command References: <20230516094711.57265-1-simon.farre.cx@gmail.com> <83v8gsz4mm.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: > From: Simon Farre > Date: Thu, 18 May 2023 13:12:23 +0200 > Cc: Simon Farre via Gdb-patches > > > Also, I don't think I understand this description. What did you mean by "source-level steps to > columns"? > > I was attempting to signal that this is a "pure" source-level command, i.e. that it's not > like "step", "stepi", or "nexti". After some discussion on IRC with Andrew Burgess, > he pointed out to me that these commands are not supposed to work like this new proposed > command > because they were not "source level commands" but "instruction level commands" so I figured I'd run > with that distinction/definition. The "source-level" part is clear, but what about "stepping to columns"? The command steps by expressions, not by columns. > > It would be good to mention the version of DWARF2 that supports the > > necessary information, and perhaps also the compilers known to emit > > it. At least for GCC, I'd certainly like to see this in the manual. > > I actually wrote this but decided to remove it which was something along the lines of > "Column metadata has been supported since DWARF 2.0 (1992) and as such seem to be > emitted by a lot of compilers I've tested, like g++, clang, rustc etc." > > Where would you want me to put the information about compilers and compatibility with emitting > column data? 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.) > > Two spaces there. More importantly, what does current column measure > > in this case? Is that a character number from beginning of source > > line, a byte number since the beginning of line, or the visual column > > (which can be different from the character number if some characters > > are double-width)? How many columns is a TAB? > > > IOW, we must explain the manual what we mean by "column" here. It > > isn't trivial. > > I have tested two different versions of GCC, clang and 1 version of the rust compiler > and they all emit "columns" on a byte-level. So a smilie face with 4 bytes, will be 4 columns. > I expect this to be the case for all DWARF-compliant compilers. Where would you like > me to put this information? I could not find any information about this in the DWARF standard > but seeing as how the two major C/C++ compilers (as well as the Rust compiler) > emit it as such, then I think it's safe to assume this is how it's intended to be? 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.