From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 47601 invoked by alias); 18 May 2018 22:06:09 -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 47585 invoked by uid 89); 18 May 2018 22:06:09 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 spammy=picked X-HELO: mailsec115.isp.belgacom.be Received: from mailsec115.isp.belgacom.be (HELO mailsec115.isp.belgacom.be) (195.238.20.111) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 18 May 2018 22:06:07 +0000 IronPort-PHdr: =?us-ascii?q?9a23=3A1xRIKh1kBE4He4W/smDT+DRfVm0co7zxezQtwd8Z?= =?us-ascii?q?seITK/ad9pjvdHbS+e9qxAeQG9mDsLQc06L/iOPJYSQ4+5GPsXQPItRndiQuro?= =?us-ascii?q?EopTEmG9OPEkbhLfTnPGQQFcVGU0J5rTngaRAGUMnxaEfPrXKs8DUcBgvwNRZv?= =?us-ascii?q?JuTyB4Xek9m72/q99pHPbQhEniaxba9vJxiqsAvdsdUbj5F/Iagr0BvJpXVIe+?= =?us-ascii?q?VSxWx2IF+Yggjx6MSt8pN96ipco/0u+dJOXqX8ZKQ4UKdXDC86PGAv5c3krgfM?= =?us-ascii?q?QA2S7XYBSGoWkx5IAw/Y7BHmW5r6ryX3uvZh1CScIMb7S60/Vza/4KdxUBLmiz?= =?us-ascii?q?oJOT4n/m/ZiMNwgr5UrhWuqBJw2IPUfIOYOeBicq7HYd8XR2xMVdtRWSxbBYO8?= =?us-ascii?q?apMCAfABPeZZq4n9pkMOrQOgCgKxBOzg0CVIhnjv3a0n0uQuDxvG3Bc9FN8JqH?= =?us-ascii?q?TUrNT1NKMTUeCt1KnH0y/Pbv1M1jfn74jIaw0hofCSUrJqasrc0lIvFwDFj1WW?= =?us-ascii?q?t4PlIymZ2f8TvGWC6edrSOGhi3Y/pg1svjSiwt0ghpTHi44J0FzI6Dt1zYcvKd?= =?us-ascii?q?GmRkN3f9ipG4ZKuS6ALYt5WMYiTnltuCY917IJp4a2fDMPyJQ73x7fbOGHc5SQ?= =?us-ascii?q?7hLjSumRJTB4iWpgeL2inxqy8E6gxfPgVsSszVpGsi5InsPRun0DyxDf8NWLRu?= =?us-ascii?q?V880u7xzqC2R7f5vlBIU8ulKrbL5AhwqQ3lpoWqUnDBi/2mETyjK+XbkUk4van?= =?us-ascii?q?5/7pY7r8vJ+cMJZ0ihz/MqswgMy/Gv81MhMNX2mb/+SzyqHj8VfiT7pUlvE2iL?= =?us-ascii?q?XWsIjGJcQHoa60GxRV0ocm6xmlFTem088VnWIGLFJAYh2HlYvpN0vSL//iFf2/?= =?us-ascii?q?mUijkC93x/DaOb3sGprNIWXYn7v4ZbZy8VJcxxYzzd9B/JJZEaoBIPXuWk/rqN?= =?us-ascii?q?PXEBE4PBauw+n5Etl90ZkeWW3cSpOeZZjTtFiOrscmOeKMZcdBozf4IuImz+Xv?= =?us-ascii?q?iHYjmhkWdP/tlZQbYjWgF+htI0iCSWHrn80KHHgDpAd4S/bl23OYVjsGX3azW6?= =?us-ascii?q?Mk/jxzN4u8Cp7eR423m/TVxCe6GpxOfm0AFVmWFm71doieQN8XazOUL9MnmDFS?= =?us-ascii?q?BuvpcJMoyRz77Fyy8LFgNOeBoiA=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A2BiAgAJTf9a/+h+gm1dHQEBBQELAYNDQ?= =?us-ascii?q?oEchByIBF+OFDEBXZM2gXgLKwGEQAKCECI0GAECAQEBAQEBAgFrKII1IoJSAQU?= =?us-ascii?q?jMzMIAw4KAgImAgI5HgYBhTqpQIIchFmDboIngQmJAD+EG4dzglQChxgDhieLC?= =?us-ascii?q?gcCgWeMcIx9kHeBJRw4gVJtU4JEgh8Xjhk9gT0IDAGOWwEB?= X-IPAS-Result: =?us-ascii?q?A2BiAgAJTf9a/+h+gm1dHQEBBQELAYNDQoEchByIBF+OFDE?= =?us-ascii?q?BXZM2gXgLKwGEQAKCECI0GAECAQEBAQEBAgFrKII1IoJSAQUjMzMIAw4KAgImA?= =?us-ascii?q?gI5HgYBhTqpQIIchFmDboIngQmJAD+EG4dzglQChxgDhieLCgcCgWeMcIx9kHe?= =?us-ascii?q?BJRw4gVJtU4JEgh8Xjhk9gT0IDAGOWwEB?= Received: from 232.126-130-109.adsl-dyn.isp.belgacom.be (HELO md) ([109.130.126.232]) by relay.skynet.be with ESMTP/TLS/AES256-GCM-SHA384; 19 May 2018 00:06:05 +0200 Message-ID: <1526681165.1604.11.camel@skynet.be> Subject: Re: [RFC 2/5] Implement frame apply [all | COUNT | -COUNT] [-FLAGS...] COMMAND From: Philippe Waroquiers To: Simon Marchi , gdb-patches@sourceware.org Date: Sat, 19 May 2018 05:16:00 -0000 In-Reply-To: <558abe97-4bae-dc11-a987-2adb7afa0f41@simark.ca> References: <20180505192804.12731-1-philippe.waroquiers@skynet.be> <20180505192804.12731-3-philippe.waroquiers@skynet.be> <558abe97-4bae-dc11-a987-2adb7afa0f41@simark.ca> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2018-05/txt/msg00431.txt.bz2 On Thu, 2018-05-17 at 21:55 -0400, Simon Marchi wrote: > > +/* Implementation of the "frame apply" command. */ > > + > > +static void > > +frame_apply_command (const char* cmd, int from_tty) > > +{ > > + int count; > > + struct frame_info *trailing; > > + > > + if (!target_has_stack) > > + error (_("No stack.")); > > + > > + count = get_number_trailer (&cmd, 0); > > + > > + if (count < 0) > > + { > > + trailing = trailing_outermost_frame (-count); > > + count = -1; > > + } > > + else > > + trailing = get_current_frame (); > > + > > + frame_apply_command_count ("frame apply", cmd, from_tty, > > + trailing, count); > > +} > > While testing this, I intuitively expected that this command would > work the same way as thread apply: take a frame number of frame number > range. I had to think for a second when this did not do as I expected: > > (gdb) bt > #0 break_here () at test.c:6 > #1 0x000055555555461a in main (argc=1, argv=0x7fffffffde78) at test.c:12 > (gdb) frame apply 0 print 123 > (gdb) frame apply 1 print 123 > #0 break_here () at test.c:6 > $6 = 123 > > So I'm wondering whether it would make more sense to have both thread apply > and frame apply work in a similar way, to avoid confusing users. When I started implementing this, I first intended to have a list of frames, or range of frames (i.e. similar to thread apply). However, I finally did the COUNT | -COUNT approach for the following reasons: * this is similar to the backtrace command * the most common use cases are to show all frames, or some innermost frames, or some outermost frames. The use case of showing some 'middle frames range' is not a likely use case (as shown by the backtrace command, that does not have such feature). Similarly, showing 'cherry picked frames' seems also unlikely to be useful. * but the real difficulty is what range syntax to use to indicate either the innermost N frames or the outermost N frames ? For the innermost, we could use e.g. frame apply 0-3 p $sp to show $sp for frame 0, 1, 2, 3. But what would be the syntax to print $sp for e.g. 5 outermost frames ? It is difficult for the user to use "absolute" numbers as the frame numbering will vary, depending on the stack depth. And we also have to find a notation to indicate that the range is at the outermost side. I could not find a reasonable way to indicate this. e.g. frame apply -0-4 p $sp looks an ugly way to indicate the outermost 5 frames. So, in summary, COUNT | -COUNT has the advantage of being compatible with backtrace/easy to understand. Of course, having it similar to backtrace make it not looking like frame apply. But IMO, that disadvantage is not major, compared to the other syntax I thought to, which will in any case differ from the thread apply syntax IMO. > > +#define FRAME_APPLY_FLAGS_HELP "\ > > +FLAGS letters are v(increase verbosity), q(decrease verbosity)\n\ > > + c(continue), s(silent).\n\ > > +Verbosity (default 2) controls what to print for a frame:\n\ > > + 0 : no frame info is printed\n\ > > + 1 : source line\n\ > > + 2 : location\n\ > > + 3 : location and address\n\ > > + 4 : source line and location\n\ > > +By default, if a COMMAND raises an error, frame apply is aborted.\n\ > > +Flag c indicates to print the error and continue.\n\ > > +Flag s indicates to silently ignore a COMMAND that raises an error\n\ > > +or produces no output." > > I would prefer if this was a const char [] rather than a macro. The macro is used to build a string literal. I quickly tried, but I found no straightforward way to build a string literal using a factorised const char [] value. Philippe