From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6646 invoked by alias); 13 Oct 2003 17:24:43 -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 6626 invoked from network); 13 Oct 2003 17:24:42 -0000 Received: from unknown (HELO mail-out3.apple.com) (17.254.13.22) by sources.redhat.com with SMTP; 13 Oct 2003 17:24:42 -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 h9DHOfvd028481 for ; Mon, 13 Oct 2003 10:24:41 -0700 (PDT) Received: from scv2.apple.com (scv2.apple.com) by mailgate1.apple.com (Content Technologies SMTPRS 4.2.1) with ESMTP id for ; Mon, 13 Oct 2003 10:24:11 -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 h9DHORWI009493 for ; Mon, 13 Oct 2003 10:24:27 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v606) In-Reply-To: <1065875539.13549.ezmlm@sources.redhat.com> References: <1065875539.13549.ezmlm@sources.redhat.com> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <38B36630-FDA2-11D7-BB88-000A958F4C44@apple.com> Content-Transfer-Encoding: 7bit From: Jim Ingham Subject: Re: Unambiguously specifying source locations Date: Mon, 13 Oct 2003 17:24:00 -0000 To: gdb@sources.redhat.com X-SW-Source: 2003-10/txt/msg00191.txt.bz2 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... Jim On Oct 11, 2003, at 5:32 AM, gdb-digest-help@sources.redhat.com wrote: > This isn't a proposal - I haven't clearly thought out the details - > just > some ramblings on a problem. > > I would like to have a way to clearly identify a location, not by > address. > Primarily this would be for breakpoints; when we re-read an objfile's > symbols, we need to replace breakpoints somehow, and the more of the > user's > intent we can preserve the better. Obviously this is not a perfectly > solvable problem, but we can do pretty well. > > It's an important problem, too. Not only is recompile/reload a pretty > common thing to do, but IDEs which save breakpoints across sessions > would > use this also. Et cetera. > > I think it's only source locations that I need to identify in this > way, in > the short term, but we should use an extensible syntax. For a > way-beyond-current-state example, consider an inlined function with > multiple > inlined instances. One of the simpler things we could do is: > > record the number of instances in this objfile before reloading > check the number of instances in this objfile after reloading > if same, then we can preserve things like the breakpoint enabled > state > to the new set > if not, punt - enable all? warn? > > The goal there being to preserve the status of particular breakpoints > across > reload, as best as we can, when unrelated changes are made to the > source. > Someone fixes emit_foo () and recompiles and we try not to disturb > their > eight disabled and one enabled breakpoint on inlined copies of > obstack_alloc > where they were tracking the allocation of the bad object. > > We could be much more thorough. Try this on for size: > Record the source location of the emitted function which contains > each > inlined instance, as unambiguously as we can. > Record the inlining path. > > The result would look something like (I don't like this syntax, just > illustrating): > [libfoo.so.2][foo-1.cc:foo_func:75][bar-1.h:inline_one:33]\ > [bar-1.h:inline_two:36] > Then after reload if the path still leads to an inlined copy of > inline_two > we can re-establish the breakpoint. Or there are various fuzzy > matching > things we could do. Et cetera. > > Generating such paths would be useful for output anyway; and if we can > do > them in such a way as to accept them for input too, that would be > useful to > our users. We could also accept as input ambiguous paths and do > basically > wildcarding: > break [libfoo.so.2][bar-1.h]inline_two > > Wouldn't that be nice? > > The use of braces is not entirely coincidental. decode_line_1 > currently > does not accept anything that starts with a '[' as far as I can see; > ObjC > selectors always have +[ or -[. Using braces simplifies quoting and > parsing > quite a bit. And it could be extended as necessary without too much > trouble. > > There are other problems: for instance, we might want to use linker > names > for non-inlined functions where possible, for GDB-generated location > descriptions; that would handle keeping track of which constructor we > were > stopped on. Otherwise we'd need some other method for that. > > Another nice thing to have might be an element in that list describing > C++ template instantiation. Not sure if that's necessary or should > just be > added to the function name as needed. > > Include paths may also be needed. This happens in C, with static > functions > in headers. Here's an example that bites me all the time: > [libbfd.so][elf32-i386.c][elflink.h:2300] > [libbfd.so][elf32-sparc.c][elflink.h:2300] > or maybe it should be: > [libbfd.so][elf32-i386.c:elflink.h:2300] > [libbfd.so][elf32-sparc.c:elflink.h:2300] > The latter, I think. > > Right now the equivalent to this is handled in > build_canonical_line_spec. > It's a little simple-minded; there are plenty of cases it doesn't > handle. > It would be nice to do better. > > Any specification of this should be explicit about quoting rules, > comma, > dammit. > > What other thoughts do you all have? Am I on the right track, should > we > draw up a formal specification for these? > > -- > Daniel Jacobowitz > MontaVista Software Debian GNU/Linux Developer > -- Jim Ingham jingham@apple.com Developer Tools Apple Computer