From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24304 invoked by alias); 13 Jun 2012 13:29:38 -0000 Received: (qmail 24283 invoked by uid 22791); 13 Jun 2012 13:29:36 -0000 X-SWARE-Spam-Status: No, hits=-5.4 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-qc0-f169.google.com (HELO mail-qc0-f169.google.com) (209.85.216.169) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 13 Jun 2012 13:29:23 +0000 Received: by qcsd16 with SMTP id d16so362914qcs.0 for ; Wed, 13 Jun 2012 06:29:22 -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:x-system-of-record:x-gm-message-state; bh=mxj46G3mUkmjoEHftACJXWscvGc7kCpyzVeAeh0Ptoo=; b=Xi0rAuxnZ/mmJi69XZXM3WmOf2L3XdHEgzFletg+6Wzq4qXW+8Is1VPKbXkqxRQ/zK lr22qbRd4LZIr0U87KneDS481D2bMRWF7tqiS8wgXKAAiH4XmrB09YZkdixc2FKQGwR1 XW3M4921zvmP1Nj/B77if3KAqjLJzr6Xt7N3Cv/Mvo2T44KL/R7VwtmOMPwUyIHH7/rA poSR28jMrnCyCldpvD2k1CzcZ7fiRa+Z3IvtQyzGDp1vH1uQi+xsQYLP95Lfa5skgjYq ZreYDvhZCV3obOslEZLklpigxPC8qs6SZFy6A2v5JraXyglVO9DDHHGCM6qXG9SlX5rq PU/Q== Received: by 10.224.219.67 with SMTP id ht3mr14461150qab.0.1339594162757; Wed, 13 Jun 2012 06:29:22 -0700 (PDT) MIME-Version: 1.0 Received: by 10.224.219.67 with SMTP id ht3mr14461142qab.0.1339594162669; Wed, 13 Jun 2012 06:29:22 -0700 (PDT) Received: by 10.224.63.209 with HTTP; Wed, 13 Jun 2012 06:29:22 -0700 (PDT) In-Reply-To: References: Date: Wed, 13 Jun 2012 13:29:00 -0000 Message-ID: Subject: Re: [RFC - Python Scripting] Add 'end' attribute to gdb.Symtab_and_line From: Siva Chandra To: Doug Evans Cc: gdb-patches@sourceware.org Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true X-Gm-Message-State: ALoCoQmVQhswLtDtty+r6CxIbnBI65VgMZqt06eBl7HQnARDC3YW0lkzLKzTqaAqLhKlBfixjyH+pyIgPK82ZPD5+J8/lostZTyTsUmbv/axdrkQzyCPq6CAH//HdzXenZL5NqeDtUGZUGjrUdBXoExKKo1l70yaoA== 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/msg00401.txt.bz2 On Wed, Jun 13, 2012 at 12:10 AM, Siva Chandra wrote: > 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. 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