From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23988 invoked by alias); 10 May 2010 23:28:02 -0000 Received: (qmail 23963 invoked by uid 22791); 10 May 2010 23:28:00 -0000 X-SWARE-Spam-Status: No, hits=-2.1 required=5.0 tests=AWL,BAYES_00,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from smtp-outbound-1.vmware.com (HELO smtp-outbound-1.vmware.com) (65.115.85.69) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 10 May 2010 23:27:53 +0000 Received: from jupiter.vmware.com (mailhost5.vmware.com [10.16.68.131]) by smtp-outbound-1.vmware.com (Postfix) with ESMTP id 41CCA1E001; Mon, 10 May 2010 16:27:52 -0700 (PDT) Received: from msnyder-server.eng.vmware.com (promd-2s-dhcp138.eng.vmware.com [10.20.124.138]) by jupiter.vmware.com (Postfix) with ESMTP id 36DB8DC0F0; Mon, 10 May 2010 16:27:52 -0700 (PDT) Message-ID: <4BE89677.60607@vmware.com> Date: Mon, 10 May 2010 23:28:00 -0000 From: Michael Snyder User-Agent: Thunderbird 2.0.0.22 (X11/20090609) MIME-Version: 1.0 To: Stan Shebs CC: Joel Brobecker , "gdb-patches@sourceware.org" Subject: Re: RFC: new struct breakpoint component cond_language... References: <20100510215421.GJ2957@adacore.com> <4BE895C2.6090706@codesourcery.com> In-Reply-To: <4BE895C2.6090706@codesourcery.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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: 2010-05/txt/msg00240.txt.bz2 Stan Shebs wrote: > Joel Brobecker wrote: >> So, taking both of these elements into account, I deduce that >> breakpoints should also store a condition_language which should be >> used in order to parse our condition, because it can be different >> from the breakpoint language. >> > > Tracepoints add an extra wrinkle to this concept - when connecting to a > target that is currently running a trace, tracepoint conditions can be > uploaded from the target, and in their original source form, and so have > to be reparsed. So to make this work in the multi-language case, it > seems like the tracepoint download should include the language somehow. > > But then I wonder - when uploading a tracepoint, we receive both the > computed address and the source form of that address, so in theory we > can always deduce the correct language by working back from the > tracepoint address. And if that's true, then wouldn't the language of > the condition be expected to be the same as the language of the > location? Are tracepoints then just a special case in which the > condition language does not need to be recorded? Hmmm... doesn't the breakpoint struct already record (as you mention) the "source form" (ie. a string) of the address? In which case, could we not always derive the source language? Oh, well, what if it's just a function name? Is that enough?