From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 59819 invoked by alias); 29 Jun 2018 20:16:00 -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 57812 invoked by uid 89); 29 Jun 2018 20:15:56 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-4.0 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 spammy=H*F:D*be, UD:be, hear, HContent-Transfer-Encoding:8bit X-HELO: mailsec107.isp.belgacom.be Received: from mailsec107.isp.belgacom.be (HELO mailsec107.isp.belgacom.be) (195.238.20.103) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 29 Jun 2018 20:15:49 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=skynet.be; i=@skynet.be; q=dns/txt; s=securemail; t=1530303343; x=1561839343; h=message-id:subject:from:to:cc:date:in-reply-to: references:mime-version:content-transfer-encoding; bh=mWzyX0hoWMjMvLYr+uGVKwzq5Z5MIZReGPBRoKLp1ZI=; b=P/5oGw39HZBWxJV6IkQzS8TYP9nqhBB4dg/OeHCbmrK1CHjFPQ/a/MAA G+8tqKgAIgg5GJ/9ZAJdCZSvOVSw8A==; Received: from 224.41-64-87.adsl-dyn.isp.belgacom.be (HELO md) ([87.64.41.224]) by relay.skynet.be with ESMTP/TLS/AES256-GCM-SHA384; 29 Jun 2018 22:15:40 +0200 Message-ID: <1530303340.1512.15.camel@skynet.be> Subject: Re: [RFA_v3 0/8] Implement 'frame apply COMMAND', enhance 'thread apply COMMAND' From: Philippe Waroquiers To: Andrew Burgess Cc: gdb-patches@sourceware.org Date: Fri, 29 Jun 2018 20:16:00 -0000 In-Reply-To: <20180629122158.GH15881@embecosm.com> References: <20180624183708.888-1-philippe.waroquiers@skynet.be> <20180629122158.GH15881@embecosm.com> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-IsSubscribed: yes X-SW-Source: 2018-06/txt/msg00732.txt.bz2 On Fri, 2018-06-29 at 13:21 +0100, Andrew Burgess wrote: > This patch makes it much clearer (I think) that there are multiple was > to IDentify a frame, level, address, function-name. > > I wonder if using the keyword 'id' might be confusing were my patch to > end up being merged? Would a consistent 'level' be better? > > Interested to hear your thoughts... Counting in gdb.texinfo, I see 5 references to regexp 'frame.id' (but I am not at all sure that these are referencing the #integer that backtrace shows). I see one reference to 'frame.level'. I see 8 references to 'frame.number', and some of these references are explicitly explaining that backtrace shows a frame number. In the code, I see a bunch of occurrences of 'frame.level' and much more of 'frame.id', but as far as I can see, frame id is rather the internal 'struct frame_id' concept. frame.number seems not used too much in the code, except as traceframe_number So, for me, fine to replace Usage: frame apply id ID... [FLAG]... COMMAND ID is a space-separated list of IDs of frames to apply COMMAND on. by Usage: frame apply level LEVEL... [FLAG]... COMMAND    LEVEL is a space-separated list of frames identified by their level to apply COMMAND on. But if we want to keep the current use of frame number, it should rather be  Usage: frame apply number NUMBER... [FLAG]... COMMAND NUMBER is a space-separated list of frames identified by their number to apply COMMAND on. Whatever we take, we have to ensure that gdb.texinfo systematically use  it to identify a frame as shown by backtrace (#integer). All the above change is quite mechanical, but that is better done once feedback is given e.g. by Pedro over this patch RFA_v3 and about your patch. And then, we need to see in which order which patch is applied. (I slightly prefer my patch first, but I guess you slightly prefer your patch first :). So let e.g. Pedro decide about which one is ready to go in first. In summary: review needed, and then a decision about the above and about which patch goes first ... Thanks Philippe