From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30640 invoked by alias); 27 Jul 2012 13:27:27 -0000 Received: (qmail 30629 invoked by uid 22791); 27 Jul 2012 13:27:26 -0000 X-SWARE-Spam-Status: No, hits=-7.5 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,KHOP_THREADED,RCVD_IN_DNSWL_HI,RCVD_IN_HOSTKARMA_W,SPF_HELO_PASS,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 27 Jul 2012 13:27:04 +0000 Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q6RDQxT3005255 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 27 Jul 2012 09:27:00 -0400 Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.ams2.redhat.com [10.39.146.11]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id q6RDQwd5022483; Fri, 27 Jul 2012 09:26:58 -0400 Message-ID: <50129721.5010900@redhat.com> Date: Fri, 27 Jul 2012 13:27:00 -0000 From: Pedro Alves User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:14.0) Gecko/20120717 Thunderbird/14.0 MIME-Version: 1.0 To: Yao Qi CC: gdb-patches@sourceware.org Subject: Re: [PATCH 2/6] allow to suppress more mi notification References: <1343146252-22558-1-git-send-email-yao@codesourcery.com> <1343146252-22558-3-git-send-email-yao@codesourcery.com> <5011628A.3000707@redhat.com> <1705340.40y1UybpUm@qiyao.dyndns.org> In-Reply-To: <1705340.40y1UybpUm@qiyao.dyndns.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit 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 X-SW-Source: 2012-07/txt/msg00675.txt.bz2 On 07/27/2012 03:57 AM, Yao Qi wrote: > On Thursday, July 26, 2012 04:30:18 PM Pedro Alves wrote: >>> -extern int mi_suppress_breakpoint_notifications; >>> + >>> +enum MI_SUPRESS_NOTIFICATION { MI_SUPPRESS_BREAKPOINT }; >>> +extern int mi_suppress_notification[]; >>> >>> >> >> Quite frankly, I don't see how putting these in an array is better than >> a separate global for each. The memory used is the same, and with separate >> globals, it's a little easier to debug from a top gdb (just print >> mi_suppress_ to see the list of possibilities, etc.) Are you planning >> on doing something over the whole array, that is abstracted from the >> semantics of each element of the array? > > The intention of this change is to avoid introducing more global variables to > suppress different types of notification. More global variables, or more entries in a global array is really not very much different.. And you still have to add global macros, one for each entry in the array, so in the end, you end up with _more_ global symbols total. > I plan to add more notifications > here (for register change, memory change, trace experiment change, etc), and > we need more suppress flags for them. Array makes sense here. > > AFAICS, I don't do something over the whole array. Array is really the worse choice. Use it only when you have the need to iterate over the elements. Otherwise, it's just harder to debug. "p mi_suppress_notification" will show you an array of integers. Once you have a few, that will just be cryptic output, and you'll have to do "p mi_suppress_notification[...]" to make some sense out of it. If you want to group the variables together, then the first choice should be a struct instead. Then you can still inspect the variables easily from a top gdb. E.g., struct { int breakpoint : 1; int option_changed : 1; ... } mi_suppress_notification; And then you can have: (gdb) p mi_suppress_notification (gdb) p mi_suppress_notification. (gdb) p mi_suppress_notification.breakpoint etc. -- Pedro Alves