From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21853 invoked by alias); 18 Jul 2012 15:11:57 -0000 Received: (qmail 21800 invoked by uid 22791); 18 Jul 2012 15:11:54 -0000 X-SWARE-Spam-Status: No, hits=-6.3 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,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; Wed, 18 Jul 2012 15:11:39 +0000 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q6IFBdD4006173 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 18 Jul 2012 11:11:39 -0400 Received: from psique (ovpn-113-52.phx2.redhat.com [10.3.113.52]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id q6IFBaUn021163; Wed, 18 Jul 2012 11:11:37 -0400 From: Sergio Durigan Junior To: Jan Kratochvil Cc: gdb-patches@sourceware.org Subject: Re: [RFA 4/4] Improved linker-debugger interface References: <20120712123406.GA29236@redhat.com> <20120712123617.GE29236@redhat.com> <20120713094150.GB2689@redhat.com> <20120718142813.GA14796@host2.jankratochvil.net> X-URL: http://www.redhat.com Date: Wed, 18 Jul 2012 15:11:00 -0000 In-Reply-To: <20120718142813.GA14796@host2.jankratochvil.net> (Jan Kratochvil's message of "Wed, 18 Jul 2012 16:28:13 +0200") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii 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-07/txt/msg00267.txt.bz2 On Wednesday, July 18 2012, Jan Kratochvil wrote: > On Tue, 17 Jul 2012 20:11:07 +0200, Sergio Durigan Junior wrote: >> On Friday, July 13 2012, Gary Benson wrote: >> > + arg1: Lmid_t lmid (mandatory) >> > + arg2: struct r_debug *r_debug (mandatory) >> > + arg3: struct link_map *new (optional, for incremental updates) */ >> >> I guess you could rename the arguments listed here to 'arg0', 'arg1' and >> 'arg2', because `evaluate_probe_argument' takes these numbers as >> arguments. Or you could explicitly say that here. Otherwise it will >> confuse the reader, IMO. > > Could you clarify the 1-counting vs. 0-count in: evaluate_probe_argument, > compile_to_ax. Maybe it is not fully clear even in > sym_evaluate_probe_argument, sym_compile_to_ax. > (It is already clear in probe_safe_evaluate_at_pc.) Ok. >> > + debug_base = value_as_address (evaluate_probe_argument (os->objfile, >> > + pi->probe, 1)); >> >> ...but what would happen if `evaluate_probe_argument' returned NULL? >> It's better to check this, because `value_as_address' calls `value_type' >> which does not check NULL pointers. >> >> Currently, only the SystemTap backend is implemented, and if it returns >> NULL in this case it would be an error, but it's better to guard your >> code IMO. > > Currently the API comment defines "returning a value corresponding to it.". > There is no "or NULL if evaluation error occurs" or anything like that, > therefore it IMNSHO means the returned value is non-NULL. > > Therefore I find correct for Gary to assume the returned value is non-NULL. I will not argue. -- Sergio