From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5799 invoked by alias); 10 Aug 2011 14:24:21 -0000 Received: (qmail 5791 invoked by uid 22791); 10 Aug 2011 14:24:21 -0000 X-SWARE-Spam-Status: No, hits=-7.3 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_HI,RP_MATCHES_RCVD,SPF_HELO_PASS 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, 10 Aug 2011 14:24:05 +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 p7AENu2d003512 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 10 Aug 2011 10:23:56 -0400 Received: from ns3.rdu.redhat.com (ns3.rdu.redhat.com [10.11.255.199]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id p7AENtWI012422; Wed, 10 Aug 2011 10:23:56 -0400 Received: from barimba (ovpn01.gateway.prod.ext.phx2.redhat.com [10.5.9.1]) by ns3.rdu.redhat.com (8.13.8/8.13.8) with ESMTP id p7AENont006415; Wed, 10 Aug 2011 10:23:52 -0400 From: Tom Tromey To: Pedro Alves Cc: Jan Kratochvil , gdb-patches@sourceware.org, Sergio Durigan Junior Subject: Re: [PATCH 2/6] Introduce `pre_expanded sals' References: <201104121218.08910.pedro@codesourcery.com> <20110412115308.GA384@host1.jankratochvil.net> <201104121430.24596.pedro@codesourcery.com> Date: Wed, 10 Aug 2011 14:24:00 -0000 In-Reply-To: (Tom Tromey's message of "Wed, 27 Jul 2011 10:58:07 -0600") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain 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: 2011-08/txt/msg00220.txt.bz2 Tom> Yesterday I started wondering if this patch series could go in if Tom> re-expressed as catchpoints. I looked into this quite a bit and I think it won't work out. It works out fine for plain catchpoints, but it still falls down if we want to set tracepoints at SystemTap probes. Doing this means we get into the same issues with multiple locations that we were trying to avoid by moving to catchpoints. Now I am considering a third approach, namely rebasing the SystemTap work on the ambiguous linespec proposal that I'm implementing (this will solve the multiple location problem), and then using option-like syntax for probes, like "break -p probe". Tom