From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7742 invoked by alias); 13 Jun 2012 17:08:56 -0000 Received: (qmail 7725 invoked by uid 22791); 13 Jun 2012 17:08:54 -0000 X-SWARE-Spam-Status: No, hits=-5.5 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,KHOP_RCVD_TRUST,KHOP_THREADED,RCVD_IN_DNSWL_LOW,RCVD_IN_HOSTKARMA_YE,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mail-vb0-f41.google.com (HELO mail-vb0-f41.google.com) (209.85.212.41) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 13 Jun 2012 17:08:41 +0000 Received: by vbkv13 with SMTP id v13so686367vbk.0 for ; Wed, 13 Jun 2012 10:08:40 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding:x-system-of-record :x-gm-message-state; bh=HGYn2SrqatYQU0OgfYLaL2Y9uLkwuk3S4DIfZZHybUU=; b=ZB1o0ufNsTy0Qby7ceZCc6pnOXsnhXz+Z5rEsMvrDVvt/ZOxL+AAGOhR7aWJsy/AeP TETOrK7KKh10L3gTI0Na+zMr0gWX/R/G7IPLdM34+NFVoE737aUthWdbPq+vJAMBnWpT +O/HGPoiPYok+5Ss32nKE61Blpsq3WYA3vjGaQ4XbacSlvFZr7lVmrlKSDP7oSsIXnhI yO38hi2XrJuuMCM76CRu8881FAtZPny/g8g8XMEUNxyG7bd6jIr3D2ZuWy+Ww0qK89Y8 qYP5T0lJRzOp+yD1FhO3yEHnlllTh90i0M95aFLUQDTbI/czHSIcIKK/G6cl11VI8j/C B1Fw== Received: by 10.52.17.80 with SMTP id m16mr14261445vdd.71.1339607320649; Wed, 13 Jun 2012 10:08:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.17.80 with SMTP id m16mr14261435vdd.71.1339607320334; Wed, 13 Jun 2012 10:08:40 -0700 (PDT) Received: by 10.52.161.199 with HTTP; Wed, 13 Jun 2012 10:08:40 -0700 (PDT) In-Reply-To: References: Date: Wed, 13 Jun 2012 17:08:00 -0000 Message-ID: Subject: Re: [RFC - Python Scripting] Add 'end' attribute to gdb.Symtab_and_line From: Doug Evans To: Siva Chandra Cc: gdb-patches@sourceware.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true X-Gm-Message-State: ALoCoQkKxJgfa9RpWtcNBoeyNjUuHQvSo7fA4Srn+2HzjRGjD2Igz2YfxJ55EmxNNmaXGQ0dhkFmgemxnWW/SBxr68CZ1cG7f4mhUG9aWldTjR9mBPO6ZoA2SR6gscGllOy0BVh5XA+gKE0a4aVEf8axdaGO6fJ6QQ== X-IsSubscribed: yes 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-06/txt/msg00425.txt.bz2 On Wed, Jun 13, 2012 at 6:29 AM, Siva Chandra wrot= e: > On Wed, Jun 13, 2012 at 12:10 AM, Siva Chandra w= rote: >> I have changed the behavior to [pc, end_pc] as this (at least the >> name) feels more meaningful to me. But, why was right open behavior >> chosen for internal code? Even the two-argument flavor of the >> 'disassemble' command has right open behavior. > > Actually, I would like to take this back. I think, wrt 'disassemble' > command, it is essentially disassembling all instructions which fully > fall in the range provided as argument. Wrt symtab_and_line.end, if we > were to expose it as end_pc in the Python API, then I think it should > correspond to the PC value for the last instruction of that line of > source and not the last address in the range. And, if that were to be > the case, I do not think it is very practical as it does not indicate > where the next instruction starts. With the other choice, where in > end_pc indicates the last address in the range, the name end_pc > becomes a misnomer. > > From my personal point of view, I see two options: > > 1. Call this new attribute 'last' and let it indicate the last address > in the range. > =A0 or > 2. Call this new attribute 'next_start' and let it indicate the start > PC of the next instruction after the last instruction of the current > source line. > > Either of the above is good enough for the use case I have in mind. > > Thanks, > Siva Chandra I like "last". So the range would be [pc,last] ?