From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 91648 invoked by alias); 21 Mar 2019 14:38:38 -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 91636 invoked by uid 89); 21 Mar 2019 14:38:37 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-11.1 required=5.0 tests=AWL,BAYES_00,GIT_PATCH_1,GIT_PATCH_2,GIT_PATCH_3,SPF_PASS autolearn=ham version=3.3.1 spammy=became X-HELO: eggs.gnu.org Received: from eggs.gnu.org (HELO eggs.gnu.org) (209.51.188.92) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 21 Mar 2019 14:38:35 +0000 Received: from fencepost.gnu.org ([2001:470:142:3::e]:52492) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1h6yq1-0005sI-8N; Thu, 21 Mar 2019 10:38:33 -0400 Received: from [176.228.60.248] (port=4257 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1h6yq0-0004Wp-MK; Thu, 21 Mar 2019 10:38:33 -0400 Date: Thu, 21 Mar 2019 14:38:00 -0000 Message-Id: <838sx8uwbb.fsf@gnu.org> From: Eli Zaretskii To: Simon Marchi CC: tom@tromey.com, gdb-patches@sourceware.org In-reply-to: <57558f60-8254-931f-846b-bdd6b60f5798@simark.ca> (message from Simon Marchi on Wed, 20 Mar 2019 21:55:43 -0400) Subject: Re: [PATCH 00/16] Add styling to the gdb CLI and TUI References: <20181128001435.12703-1-tom@tromey.com> <83k1kxfzwo.fsf@gnu.org> <8736rja4i8.fsf@tromey.com> <83r2brhw8k.fsf@gnu.org> <87h8cmh1wg.fsf@tromey.com> <83va12gz8j.fsf@gnu.org> <87mumeb935.fsf@tromey.com> <83d0n8eyzw.fsf@gnu.org> <87d0n6adk2.fsf@tromey.com> <83imwyee29.fsf@gnu.org> <87d0n67d29.fsf@tromey.com> <83imwwc7pj.fsf@gnu.org> <57558f60-8254-931f-846b-bdd6b60f5798@simark.ca> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-IsSubscribed: yes X-SW-Source: 2019-03/txt/msg00457.txt.bz2 > Cc: gdb-patches@sourceware.org > From: Simon Marchi > Date: Wed, 20 Mar 2019 21:55:43 -0400 > > Ah, I noticed this because you changed the subject in your ping :). The original one evidently failed to draw attention ;-) > This would be very useful, especially that we can quite easily query > this from MI as well as Python. Thanks, I agree. > > --- a/gdb/doc/gdb.texinfo > > +++ b/gdb/doc/gdb.texinfo > > @@ -11197,7 +11197,7 @@ > > @vindex $_tlb@r{, convenience variable} > > The variable @code{$_tlb} is automatically set when debugging > > applications running on MS-Windows in native mode or connected to > > -gdbserver that supports the @code{qGetTIBAddr} request. > > +gdbserver that supports the @code{qGetTIBAddr} request. > > @xref{General Query Packets}. > > This variable contains the address of the thread information block. > > This looks like an unintended change. No, it's not unintended. I mentioned that in my preamble: > (Note that I took this opportunity to clean up whitespace in top.c, > I hope it's OK to do that as part of unrelated code changes.) > I know we plan to move to a version scheme where we don't have a "patch" > number (a third number), but just in case, maybe we could plan for it anyway > just in case it ever changes again in the future (I don't expect it will, > but we never know. > > So something like MAJOR * 10000 + MINOR * 100 + PATCH * 100 > > Also, it means that in your example, 9.11.90 would produce 091190. I think > it's better if we are able to distinguish 9.11.90 from 9.12. The idea was that we don't need to distinguish between them. This feature is intended to be used in scripts that need to know when a certain feature became available, so IMO resolution below XX.YY is not needed, because any XX.YY.ZZ version is just a snapshot of XX.YY+1. > Also, we should consider doing like Python does, and encode different numbers > in different bytes: > > https://docs.python.org/3/c-api/apiabiversion.html > > So we could say ((MAJOR << 16) | (MINOR << 8) | PATCH), for example. The > advantage with this is that it's easy to to isolate a particular number > using bitshifts and masks. I know it would be possible as well in decimal > to isolate a particular number, but it's just more convenient in hex. I don't have a strong opinion, but I do have a weak one: the decimal "encoding" makes it much easier for humans to construct version numbers, they don't need to convert to hex. > > - As remote.c is used much more than remote-e7000.c, it was changed > > + As remote.c is used much more than remote-e7000.c, it was changed > > back to 2 seconds in 1999. */ > > Some more unintended changes? It's intended, see above. Thanks for the review.