From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16503 invoked by alias); 3 Aug 2014 00:22:36 -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 16489 invoked by uid 89); 3 Aug 2014 00:22:35 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.2 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW,RP_MATCHES_RCVD,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mail-vc0-f175.google.com Received: from mail-vc0-f175.google.com (HELO mail-vc0-f175.google.com) (209.85.220.175) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Sun, 03 Aug 2014 00:22:34 +0000 Received: by mail-vc0-f175.google.com with SMTP id ik5so8876688vcb.20 for ; Sat, 02 Aug 2014 17:22:32 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=HGh/K1z7OP5xmdD0kUtlr7LJWBbwiYrCvVNR2ycJar0=; b=Bit1GHe81+s32zIbxDf7YEVfUG77RTK1ZHf/2Cj3xhO4NyD0Pzyqi/Hsdy2PNaOkvO 1zRUzawopn2avvMnHkQRMq4HjTAswdzH5tTluhppy7aniJPpND7pLAxC/5IgS0qXGyiA Ipq6BRGGXsMSVh5IxEVHLV7yK9qVbuvrPhcl/ILjjjz023/KdllOIQ1pjb7N0czMMN7I z6s45Llk1soVg6fkUrbUAc3/dpkGipwsm4I8U/b/uKQoOc7VcRKcd7PrpKw5A+0JakOP Pn/PFHaRz/CzSx78ztyRmY8ggKgbq4JpnnGIVuY92FjjZJfhuu8aplzOjQ1QK48MGz1Q iAWA== X-Gm-Message-State: ALoCoQnfCDE+tPKWJvxtfuynDPtNsomC0o10btzTPzr79JKdV0N1KyVfREToTMWbIZbBVGHqqQal MIME-Version: 1.0 X-Received: by 10.52.1.39 with SMTP id 7mr12998252vdj.17.1407025351864; Sat, 02 Aug 2014 17:22:31 -0700 (PDT) Received: by 10.52.28.233 with HTTP; Sat, 2 Aug 2014 17:22:31 -0700 (PDT) In-Reply-To: <21469.30354.662367.622712@ruffy.mtv.corp.google.com> References: <536BC69E.9060008@redhat.com> <5388CB91.4030802@redhat.com> <21469.30354.662367.622712@ruffy.mtv.corp.google.com> Date: Sun, 03 Aug 2014 00:22:00 -0000 Message-ID: Subject: Re: [RFA 5/9] Explicit locations v2 - Add probe locations From: Doug Evans To: Keith Seitz Cc: "gdb-patches@sourceware.org ml" Content-Type: text/plain; charset=UTF-8 X-IsSubscribed: yes X-SW-Source: 2014-08/txt/msg00035.txt.bz2 On Sat, Aug 2, 2014 at 4:38 PM, Doug Evans wrote: > [...] > > diff --git a/gdb/probe.c b/gdb/probe.c > > index c7597d9..2ff5d86 100644 > > --- a/gdb/probe.c > > +++ b/gdb/probe.c > > @@ -58,7 +58,8 @@ parse_probes (struct event_location *location, > > result.sals = NULL; > > result.nelts = 0; > > > > - arg_start = EVENT_LOCATION_LINESPEC (location); > > + gdb_assert (EVENT_LOCATION_TYPE (location) == PROBE_LOCATION); > > + arg_start = EVENT_LOCATION_PROBE (location); > > > > cs = arg_start; > > probe_ops = probe_linespec_to_ops (&cs); > > @@ -173,12 +174,12 @@ parse_probes (struct event_location *location, > > { > > canonical->special_display = 1; > > canonical->pre_expanded = 1; > > - canonical->location = new_linespec_location (NULL); > > - EVENT_LOCATION_LINESPEC (canonical->location) > > + canonical->location = new_probe_location (NULL); > > + EVENT_LOCATION_PROBE (canonical->location) > > = savestring (arg_start, arg_end - arg_start); > > I see why you pass NULL to new_probe_location and then set EVENT_LOCATION_PROBE > afterwards (otherwise two copies of the string would be malloc'd, and you'd > need to deal with freeing one of them). One could add a version of > new_probe_location that took a char* and a length, but that seems excessive. > Another place where c++ would allow cleaner code. OTOH, is that, or any other variation, excessive? It's preferable to not have users of object foo know how to physically construct a foo. /just a thought for discussion's sake - I wouldn't change the patch if this is but one of many similar instances, unless it makes sense to change all of them.