From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4162 invoked by alias); 14 Oct 2003 23:47:20 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 4155 invoked from network); 14 Oct 2003 23:47:18 -0000 Received: from unknown (HELO mail-out3.apple.com) (17.254.13.22) by sources.redhat.com with SMTP; 14 Oct 2003 23:47:18 -0000 Received: from mailgate1.apple.com (a17-128-100-225.apple.com [17.128.100.225]) by mail-out3.apple.com (8.12.10/8.12.9) with ESMTP id h9ENlIk0002742 for ; Tue, 14 Oct 2003 16:47:18 -0700 (PDT) Received: from scv2.apple.com (scv2.apple.com) by mailgate1.apple.com (Content Technologies SMTPRS 4.2.1) with ESMTP id for ; Tue, 14 Oct 2003 16:46:48 -0700 Received: from [17.201.22.245] (inghji6.apple.com [17.201.22.245]) by scv2.apple.com (8.12.9/8.12.9) with ESMTP id h9ENl3WI017995 for ; Tue, 14 Oct 2003 16:47:03 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v606) In-Reply-To: <1066172792.26963.ezmlm@sources.redhat.com> References: <1066172792.26963.ezmlm@sources.redhat.com> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Jim Ingham Subject: Re: Unambiguously specifying source locations Date: Tue, 14 Oct 2003 23:47:00 -0000 To: gdb@sources.redhat.com X-SW-Source: 2003-10/txt/msg00196.txt.bz2 So one corollary that makes this easier is that instead of holding onto the requested shared library (and requested file for static functions) in the address string, we should hold them in the breakpoint structure itself. So then we don't have to worry about what the canonical form is. That too becomes simple, it is: b->requested_filename = "myFile.c" b->requested_shlib = "myShlib.dylib" And if there are any others, we can add them. So we only have to break out the specifications when the user instructs us to set the breakpoint. After that all the bits are clear. I started playing around with this for dylibs for purposes of my own... I called them requested_* because I wanted to make it clear that these were not where we found the thing, but where the user asked for the thing. It is also interesting where the breakpoint eventually landed, but that bit should be in the "implementation" side of the breakpoint. This clearly belongs in the user side... Jim On Oct 14, 2003, at 4:06 PM, gdb-digest-help@sources.redhat.com wrote: > > > On Mon, Oct 13, 2003 at 10:25:20AM -0700, Jim Ingham wrote: >> I think the intent here is great! >> >> I have a heartfelt plea, however, from one who while not as >> battle-scarred as some others, have waded my way through plenty of >> decode_line_1 bugs... >> >> Is there any way we can not have to keep overloading the expression >> parser with more specifications? It seems to me this is just a way to >> obfuscate the user's intent so that we can get it wrong trying to >> decode it later. Daniel's proposed syntax - no offense intended - is >> sufficiently awful that it should give us pause. Would: >> >> break -shlib foo.dylib -file foo.c MyStaticFunction >> >> be all that awful? This is unambiguous, represents the user's intent >> exactly, is not too hard to type, and trivial to parse. Then >> internally, the breakpoint could actually hold all these separate bits >> separately, rather than munging them into a canonical form which we >> can >> trip over later on... >> >> We will probably have to support the specifications that we do now for >> ever - though adding switches for them would allow unambiguous entry >> and would probably be taken up by a good number of users cause it is >> almost impossible to get wrong... > > Feel free to propose a better canonical form :) You basically just > did, above. We need a canonical representation, for instance: > - We use it internally to re-place breakpoints after rereading an > objfile. > - We would like to be able to display it so that breakpoints can be > saved and reloaded. > > I guess the question is whether these are useful for anything other > than specifying breakpoint (or tracepoint) locations. If not then > flags to break might be canonical enough. > > -- > Daniel Jacobowitz > MontaVista Software Debian GNU/Linux Developer > > -- Jim Ingham jingham@apple.com Developer Tools Apple Computer