From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23226 invoked by alias); 28 Feb 2018 10:29:44 -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 23191 invoked by uid 89); 28 Feb 2018 10:29:43 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.3.2 spammy=Hx-languages-length:2124, her X-HELO: 9pmail.ess.barracuda.com Received: from 9pmail.ess.barracuda.com (HELO 9pmail.ess.barracuda.com) (64.235.154.210) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 28 Feb 2018 10:29:40 +0000 Received: from MIPSMAIL01.mipstec.com (mailrelay.mips.com [12.201.5.28]) by mx1402.ess.rzc.cudaops.com (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NO); Wed, 28 Feb 2018 10:29:31 +0000 Received: from [10.20.78.147] (10.20.78.147) by mips01.mipstec.com (10.20.43.31) with Microsoft SMTP Server id 14.3.361.1; Wed, 28 Feb 2018 01:55:15 -0800 Date: Wed, 28 Feb 2018 10:29:00 -0000 From: "Maciej W. Rozycki" To: "Metzger, Markus T" CC: Andreas Arnez , "gdb-patches@sourceware.org" Subject: RE: [PATCH v2 5/7] btrace, gdbserver: remove the to_supports_btrace target method In-Reply-To: Message-ID: References: <1516976072-19282-1-git-send-email-markus.t.metzger@intel.com> <1516976072-19282-6-git-send-email-markus.t.metzger@intel.com> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-BESS-ID: 1519813771-321458-30122-50773-1 X-BESS-VER: 2018.2-r1802232356 X-BESS-Apparent-Source-IP: 12.201.5.28 X-BESS-Outbound-Spam-Score: 0.00 X-BESS-Outbound-Spam-Report: Code version 3.2, rules version 3.2.2.190507 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------- 0.00 BSF_BESS_OUTBOUND META: BESS Outbound X-BESS-Outbound-Spam-Status: SCORE=0.00 using account:ESS59374 scores of KILL_LEVEL=7.0 tests=BSF_BESS_OUTBOUND X-BESS-BRTS-Status:1 X-SW-Source: 2018-02/txt/msg00453.txt.bz2 Hi Markus, > > With the change description you have also overrun our 74-column limit: > > > Standards#Column_limits>. > > NB due to how `git log' etc. indents descriptions I prefer to stay within > > 72 columns with my own changes for a better visual effect, though you are of > > course free to use your own judgement here as long as you're within 74 columns. > > Actually, the hard limit is 80 columns. I've been using that, so far, and from > looking at other files in gdb/ it looks like others were using the 80 columns limit, > as well. Well other people doing it wrong is not an excuse I am afraid. With source files it is at least bearable, however as I wrote `git log' etc. indent descriptions by 4 characters, which means that as soon as you are beyond 76 columns lines get wrapped making text really hard to follow. Take your recent commit de65820cd69a as an example. Its description renders like this on my screen: In gdb.btrace/buffer-size.exp we explicitly ask for the BTS recording format . This may lead to spurious fails on systems where PT is being used by some ot her process at the same time. Set both PT and BTS buffer sizes to 1 and check that whatever recording form at is used will use a 4KB buffer. -- is this how you wanted it to look like? If you disagree, then please discuss and get a consensus on an update to the rules set in our wiki. They are there for a reason and please look for past discussions as to why they have been set like they are now. > > Thanks for confirming. Is there going to be any difference here for > > non-x86 targets that needs to be verified? > > They're supposed to work the same way. I.e. older gdbservers won't > advertise the packets and newer GDB's hence won't use them. And > newer gdbservers would advertise the packets and, with this patch, > fail on every request with "E.Target does not support branch tracing". > > Let me check that once for both directions just to be sure. Great, thanks! Maciej